A week ago we published the plan. This is what has landed.

Every converted OpenSecOps component now ships, on every release: hash-pinned `requirements.txt` for every Lambda function, a CycloneDX 1.6 aggregate SBOM, a per-function evidence tarball, a SLSA Build L1 in-toto provenance document, and Sigstore signature bundles on all three – verifiable with a single `cosign verify-blob`. Each repository carries a generated `SECURITY.md` with the same structure: supported versions, vulnerability channel, CVE-response SLA (critical 3 business days, high 10, medium/low next regular release), signing identities, "am I affected?" recipe. Continuous detection runs between releases via Dependabot alerts (alerts-only, no auto-PRs) and a daily scan-only workflow on every public converted repository.

The single canonical reference is Documentation/docs/security/supply-chain.md, with verification commands and an intake-questionnaire crosswalk. Each component's `SECURITY.md` links to it.

Converted (12)

- Installer
- SOAR
- Foundation-control-tower-log-aggregator
- Foundation-default-vpc-remover
- Foundation-infra-immutable-tagger
- Foundation-instance-port-report
- Foundation-limit-log-group-retention
- SOAR-all-alarms-to-sec-hub
- SOAR-detect-log-buckets
- SOAR-detect-stack-drift
- SOAR-SAM-Automating-Forensic-Disk-Collection
- SOAR-soc-incident-when-s3-tag-applied

Remaining (11)

- Foundation-AWS-Core-SSO-Configuration
- Foundation-CloudWatch2S3
- Foundation-enable-ebs-encryption-by-default
- Foundation-iam-password-policy
- Foundation-new-account-created-sns-topic
- Foundation-permission-boundary-policies
- Foundation-resource-control-policies
- Foundation-security-services-setup
- Foundation-service-control-policies
- SOAR-sec-hub-configuration
- SOAR-sec-hub-role

Documentation is out of scope: no code to convert.

Conversion is a mechanical pass at this point: scripts, template, and the dormant daily-scan workflow are already distributed to every repository. Each component lands when it lands; the GitHub Security tab is the source of truth, as before.

What's left

Framework-anchored paperwork on top of the substance already shipped: CISA SSDF self-attestation, OpenSSF Best Practices Silver, ECCN 5D002 / Exception ENC line, CRA-readiness one-pager, applications to OSS-funded audit programmes (OSTIF, Alpha-Omega, Sovereign Tech, NLnet) – outcomes documented either way.

Operational notes for upgrading

• SOAR: switch `AIProvider` to `BEDROCK` and remove the four `ChatGPT*` parameters in `Installer/apps/soar/parameters.toml` before deploying. Details in the SOAR `CHANGELOG.md` v3.0.0 entry.
• Refresh procedure. All configuration lives under `Installer/apps/`, so the simplest way onto the current posture is to remove all Foundation-* and SOAR* repos, `cd` to Installer, do a `git pull`, and then `./init` on both Foundation and SOAR before you `./deploy-all`.

This time, it's the required path for Foundation-control-tower-log-aggregator, whose public main was rebuilt from clean local releases (an authorised force-push) as part of its conversion. Routine `git pull` on an existing clone will not work cleanly there, so just get rid of the lot and let `./init` restore everything.

​Before anything else: ./deploy is unchanged. Customer-facing deployment of OpenSecOps Foundation, OpenSecOps SOAR, and every other component continues exactly as before. This is a maintainer-side and release-side change. You will not need to install new tools, modify your scripts, or migrate anything.
                                                                                                                                                                                          
What you will see – once we land it – is a SECURITY.md file appearing on each repository's GitHub Security tab, signed release artefacts on the GitHub Releases page, and SBOMs (in CycloneDX format) attached to every release. Your existing automation keeps working; new artefacts appear alongside it.

We are aiming for a defensible, framework-anchored posture — using the language enterprise FOSS intake teams already speak:                                                                

• S2C2F (Secure Supply Chain Consumption Framework, OpenSSF): Level 1 + Level 2 baseline across all components. SOAR additionally implements the locally-runnable subset of Level 3 — malware-feed scanning against the OSSF malicious-packages feed, direct-dependency provenance checks, and the time-bound CVE-response SLA — because of SOAR's privilege scope.
• SLSA (Supply-chain Levels for Software Artifacts): Build Level 1, with documented L2-adjacent controls (Sigstore signing, hash-pinned reproducible resolution, second-machine reproducibility verification). We do not claim L2 because L2 requires a hosted build platform, and our release authority remains on a maintainer machine — deliberately.                
• CISA Secure Software Development Attestation Form: filled, signed, and published as federal-intake evidence for agencies and primes that may request it.
• ECCN 5D002 / Exception ENC: explicitly stated in SECURITY.md. Standard classification for security software using cryptography; the vendor is expected to declare it.                 
• EU Cyber Resilience Act: a CRA-readiness statement covering both the 11 September 2026 vulnerability-reporting obligations and the 11 December 2027 full-application date.            

                                                                                                                                                                                          
We do not pursue S2C2F Level 3 controls that require write-capable CI infrastructure — auto-merge dependency bots, hermetic builds inside a runner — or any Level 4 control (rebuilding upstream OSS on our own infrastructure). Those are out of scope by deliberate decision, not omission. The cathedral model and the maintainer-laptop release path exist for the reasons stated at the top of this post; we do not abandon them to chase a higher framework number.   ​

We will not be commissioning a paid commercial audit from a tier-1 firm. We do not have that funding, and we are honest about it rather than hiding it.                                 
   
What we are doing instead: applying to OSS-funded audit programmes — OSTIF, OpenSSF Alpha-Omega, the German Sovereign Tech Agency, NLnet Foundation. If accepted, these programmes can fund professional audits or security work at no cost to the project. If rejected, the application itself is documented in SECURITY.md as evidence of due diligence. We may also coordinate with prospective enterprise customers' own AppSec teams under NDA — many large organisations review the code as part of intake regardless, and turning that into formal coordination is free and useful for both sides.    ​

​Gradually, one component at a time. SOAR is first, because its privilege scope is broadest and the case for the most thorough posture is strongest. Foundation and the remaining components follow the same pattern, repository by repository. Each gets its own SECURITY.md with the same structure — supported versions, vulnerability reporting channel, SLA, posture statement, signing identities, "am I affected?" guidance — so reviewers find what they expect at the same address in every component.                                 

​We will not announce per-component dates. Each component lands when it lands; the GitHub Security tab on each repository is the source of truth.

Open-source code, closed contribution governance, signed releases, hash-pinned dependencies, SBOMs per release, a concrete CVE-response SLA, and explicit alignment with the frameworks enterprise security teams already use to evaluate us. No deploy-path change. No marketing language about "industry-leading" anything — just the substance of what we are doing, and why, in the language that reviewers already know.                                                                                                                                           
                                                            
If your organisation has a FOSS intake process and you would like to discuss this before the per-component SECURITY.md files appear, contact us at [email protected].

The OpenSecOps newsletter provides updates on our open-source AWS security and operations platform. Subscribe for announcements about new features, security best practices, implementation tips, and community contributions. We'll share insights about our Foundation (AWS infrastructure best practices) and SOAR (security automation) components, along with practical guidance for deploying and managing secure cloud environments. This low-volume newsletter helps you stay informed about this project that reduces AWS setup from person-years to just days.

https://buttondown.com/opensecops

​The primary motivation behind our open source transition is straightforward: ensuring continuity and security for organisations that depend on these tools.

By open-sourcing our entire platform:

• Organisations will always have access to the source code running their security infrastructure
• The community can inspect, verify, and contribute to the security of the platform
• Long-term viability is guaranteed regardless of market conditions
• Security benefits from the collective expertise of the AWS community

Unlike many open source projects that prioritise rapid feature development, our approach is distinctly security-focused:
​

• Rigorous contribution guidelines that emphasise security above all else
• Stringent review process for all proposed changes
• Zero tolerance for security compromises in any contribution
• Controlled evolution to protect existing production deployments​​

This security-first governance model reflects the reality that OpenSecOps components are deployed in financial services and other security-sensitive environments where stability and security are non-negotiable requirements.

​Our complete platform is now open source, including:
​

• OpenSecOps Foundation: Our enterprise-grade AWS infrastructure implementation with centralised logging, SSO configuration, and stringent security best practices and protections
• OpenSecOps SOAR: Our security orchestration platform with automated incident response, forensic capabilities, automatic remediation of security issues, and AI-powered reporting
• Comprehensive Documentation: Installation guides, technical design specifications, and standard operating procedures
  
  

Everything is provided under the Mozilla Public License 2.0, offering both openness and appropriate protections. The MPL 2.0 licence was carefully chosen because it doesn't restrict users in how they implement or deploy the software, whilst ensuring that modifications to the original code remain open source. This means organisations can freely integrate OpenSecOps into their environments without licensing concerns or restrictions on their own proprietary systems.

The open source model offers the ideal path forward for these security platforms. It ensures transparency, continuity, and community engagement whilst maintaining the high security standards that our users require.

We believe that security tools should be accessible, transparent, and community-driven. By embracing open source, we're creating a foundation for more secure AWS environments across all organisations, regardless of size or industry.

Join us on this journey as we build a more secure cloud future together.

In the frenzied world of tech, where buzzwords are as common as overpriced lattes, "AI" has become the latest darling. But here's a sobering thought: recent polls suggest that touting AI use in products might actually be turning customers off. 

Why? For starters, GenAI, the current poster child of the AI world, is perceived as a young, unpredictable technology prone to hallucinations. Not exactly the qualities one wants in a cybersecurity setup.

Here's where it gets interesting. In the collective rush to either embrace or shun "AI", the industry has lumped together a veritable smorgasbord of technologies under one umbrella. Machine Learning, statistical methods, expert systems – all thrown into the same pot as GenAI and stirred with a healthy dose of hype.

This conflation is not just problematic; it's potentially dangerous. Machine Learning (ML), for instance, is the seasoned professional to GenAI's intern. It's been around the block, proven its mettle, and doesn't attempt to write poetry when asked to analyse network traffic.

Consider AWS's security suite. It's built on years of ML, statistical analysis, and logical reasoning. There are no GenAI hallucinations here. Just robust, battle-tested algorithms doing what they do best – keeping digital fortresses secure.

Now, let's talk about OpenSecOps SOAR. As AWS specialists, we've built it on top of AWS's security bedrock (pun intended), leveraging these tried-and-true AI methods. It's akin to having a team of veteran, hard-core AWS security experts working 24/7.

But OpenSecOps.org isn't Luddite. GenAI is used too – judiciously. Through AWS Bedrock and Claude 3.7 Sonnet, OpenSecOps SOAR harnesses GenAI's strengths for what it's good at: generating human-readable reports, educating developers, and summarising trends. Importantly, all data stays within AWS's walls. No wandering bits here.

The key is knowing when to use what. ML for the heavy lifting of security analysis? Absolutely. GenAI for turning that analysis into informative reports? Certainly. Numerical data precomputed for total accuracy using discrete, old-fashioned code? You bet. It's about using the right tool for the job, not jumping on the latest bandwagon.

So, the next time someone presents their "AI-powered" solution, inquire about which AI they mean. Is it the equivalent of a seasoned security professional or a chatty intern with a penchant for creative writing?

Effective cybersecurity isn't about chasing the latest fad. It's about leveraging proven technologies intelligently and using newer ones cautiously. Delegat isn't interested in riding the hype train. The focus is on keeping systems secure, using every tool at its disposal – hallucination-free.

We see open source as a strength. It's no secret that part of our offerings is open source, written by us or other reputable developers. For instance, here's the new version of our serverless log aggregation system:

https://github.com/OpenSecOps-Org/Foundation-control-tower-log-aggregator

The log aggregator is part of OpenSecOps Foundation and will massage your AWS log files to cut your log file storage costs in half, amongst other things. 

Suppose you use it with our open-source multi-account log aggregator, (https://github.com/OpenSecOps-Org/Foundation-CloudWatch2S3). In that case, you have a complete solution for automatically collecting CloudWatch logs from all accounts in an AWS organization and storing them centrally in a consistent format and structure along with all system logs. 

Best of all, it costs you absolutely nothing.

You'll find all our open-source offerings here.

Why do we do this? Because we like to get the initial complexities out of the way so we can assist our clients with the architecture that really matters. Thus, OpenSecOps Foundation has no license fee; we only charge for the time it takes us to install it. Now that's a value proposition you might want to consider.

P.S.: Apart from our open source, you'll like our proprietary security aspects too, which include fully text-based configuration and a battle-tested system to prevent any escalation of privileges, amongst other things. Full details here.