OpenSecOps Supply Chain: Where We Are Now

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.