OpenSecOps Newsletter logo

OpenSecOps Newsletter

Archives
May 5, 2026

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.

Don't miss what's next. Subscribe to OpenSecOps Newsletter:
GitHub
www.opensecops.org
LinkedIn
Powered by Buttondown, the easiest way to start and grow your newsletter.