|
SOAR 4.0.0 is released. It moves SOAR's AI analyses to the current generation of Claude models on Amazon Bedrock. It is a major release because the AI configuration changes: two parameters are removed and six take their place, so an existing installation needs a small configuration edit before it can deploy.
Why SOAR uses Claude to explain each security ticket, autoremediation and incident to the team that owns the account, and to write the weekly security report. Until now it ran on Claude Sonnet 4.5, named by a hand-written inference-profile ID in the configuration. The current Opus and Sonnet models produce better security analysis, but they take a different request (adaptive thinking with a configurable effort level) and they can decline requests. Keeping up with new models should not mean editing profile IDs or code each time, so the configuration now names models and SOAR works out the rest. Declines and the fallback Claude Opus 5.5, Opus 5 and Sonnet 5.5 have safety classifiers that can decline a request, and Anthropic notes that benign cybersecurity work can trigger them. SOAR's analyses are exactly that: defensive explanations of findings from AWS's own security services, sent only to security staff and the account's team. The prompts now state this purpose plainly, which removed most declines in our tests, but not all. So SOAR 4.0.0 requires a fallback model. When the primary model declines, SOAR asks the fallback once. The recommended fallback is Claude Opus 4.8, which has no such classifiers. Each time the fallback answers, SOAR publishes a message to a new SNS topic, `OpenSecOpsSOARAIFallbacks`, so you can see how often it happens. Subscribe to it if you want to know. Failures of any kind still go to `OpenSecOpsSOARExternalCallFailures`, and the ticket, incident notification or report is still sent, without the AI text. Configuration Six keys in `apps/soar/parameters.toml`, all required: | Key | Recommended | Meaning | | --- | --- | --- | | AIModel | anthropic.claude-opus-5-5 | The model for all analyses. Claude Opus 4.6 or Sonnet 4.6 or later. | | AIFallbackModel | anthropic.claude-opus-4-8 | Used once when the primary declines. Choose a model without classifiers. `none` disables it. | | AIRegion | `us-east-1` | The Bedrock Region SOAR calls. | | AILocality | `regional` | `regional`: processing stays within the Region's geography (US, EU, Japan, Australia and so on). `global`: any commercial Region worldwide, at slightly lower cost. | | AIEffort | `high` | How much the model thinks before answering. Opus 5.5 accepts `low`, `medium`, `high`, `xhigh` and `max`. | | AIMaxTokens | `128000` | Output cap, thinking included. At most the model's limit; 128000 for both recommended models. | SOAR asks the model for adaptive thinking with an effort level. Claude Opus 4.6 and Claude Sonnet 4.6 are the earliest models that accept both; Claude Sonnet 4.5, the model SOAR used until now, does not. Effort levels vary by model: Opus 4.6 and Sonnet 4.6, for example, have no `xhigh`. An EU organisation that wants inference to stay in the EU sets `AIRegion` to an EU Region and keeps `regional`. Claude Sonnet 5.5 at `high` is a faster alternative to Opus 5.5; keep Opus 4.8 as its fallback. Every deploy checks the configuration: SOAR looks up each model's inference profile in your Region and calls each model once. A wrong model ID, a model without a profile in the Region, an effort level or token cap the model rejects, or a model the account cannot use stops the deploy with the reason, and the previous version keeps running. SOAR 4.0.0 supports Claude models only. We intend to open it to more models in coming releases. Also in this release
Upgrading
Without step 2, the SOAR deploy stops before changing anything, with `Parameters: [AIFallbackModel, AIEffort, AIModel, AIMaxTokens, AIRegion, AILocality] must have values`. One prerequisite, which most installations already meet: Anthropic's one-time use-case form must have been submitted for the organisation (organisations already using Claude on Bedrock have done so). Each model's Marketplace subscription is created automatically on first use. More information
0 Comments
OpenSecOps is open-source security software that runs with administrator-equivalent privilege inside customer AWS organisations. This year we have been strengthening the supply chain behind it: making it possible for anyone deploying OpenSecOps to verify, mechanically, that what they are about to run is what we published, that it contains exactly the libraries we chose, and that none of those libraries is known to be vulnerable. That work is complete. What remains is paperwork. WhyThe code is public under MPL 2.0, and it is developed as a cathedral: a small core team makes every decision, external pull requests are not accepted, and each release is signed by a named maintainer identity. That model gives one chain of accountability for software that holds privileged access. It does not, by itself, answer the question a customer's security team will ask before granting that access: how do we know the bytes we deploy are the bytes you released, and what exactly is in them? Until this year, the answer was partial. Direct dependencies were range-pinned and security-sensitive libraries were tightly bounded, but transitive dependencies were resolved at build time, there was no per-release bill of materials, releases were not signed, and there was no published timeline for responding to a vulnerability. Enterprise intake processes expect all four, in the vocabulary of frameworks they already use — S2C2F, SLSA, the OpenSSF Best Practices programme, the EU Cyber Resilience Act. The PlanBring every OpenSecOps component onto one uniform posture, so that a reviewer finds the same guarantees at the same address in every repository:
Framework alignment: S2C2F Level 1 and 2 across all components (SOAR adds the locally runnable subset of Level 3), SLSA Build Level 1 with documented L2-adjacent controls. We deliberately do not claim SLSA L2, which requires a hosted build platform; release authority stays on a maintainer machine, because that is where the accountability sits. We also do not commission a paid tier-1 audit; instead we apply to OSS-funded audit programmes and document the outcome either way. We announced this plan on 28 April and reported twelve of twenty-three components converted on 5 May. What We DidThe remaining eleven components shipped on 13 May. From that date, every component the Installer deploys — the 22 repositories declared in its `apps/foundation/repos.toml` and `apps/soar/repos.toml`, plus the Installer itself — carries signed releases with the guarantees above. (Documentation has no code and is out of scope.) Two shapes of component emerged. Fifteen are Python-bearing, Lambda functions with library dependencies, and carry the full set: hash-pinned `requirements.txt`, aggregate SBOM, per-function evidence tarball, provenance, and signatures on all three. Eight are pure CloudFormation templates or JSON policy documents with no libraries at all. For those there is nothing to pin or scan, but the questions "is this what OpenSecOps published?" and "how was it built?" still apply, so a libraryless release carries a signed deterministic source archive of the tagged commit plus the same signed provenance document. The publishing tooling detects the shape from the repository itself; no per-component configuration, so the two paths cannot diverge by mistake. On the customer side, the Installer now verifies releases at three points: its own release at `./init`, each component immediately after cloning or updating it, and each component again at `./deploy` before anything is built. Verification is pure Python via the `sigstore` package, installed by the Installer's existing hash-verified pip step — no extra tooling, no login, read-only checks against public Sigstore infrastructure. During the rolling conversion an unsigned component produced a warning and continued; since 13 May that path is gone. A component whose release lacks signatures fails closed, and a release that appears to have had its signatures stripped is refused as such. OpenSSF Best Practices Passing level was attained the same day (bestpractices.dev/projects/12827). Since May the pipeline has been in routine operation. The Installer alone has shipped six further releases through it, several carrying dependency CVE fixes. Where We AreThe engineering side of the plan is done. What remains is documentation anchored to specific frameworks:
The single canonical reference for the whole posture, with verification commands and a framework crosswalk, is Documentation/docs/security/supply-chain.md. Each component's `SECURITY.md` links to it. Operational Notes for Upgrading
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
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.  OpenSecOps is open-source code under MPL 2.0, and we approach development as a cathedral, not a bazaar. The source is public – for transparency, for verification, for security review by anyone who wants to read it. But contribution is closed. External pull requests are not accepted. Design decisions, architectural changes, and dependency updates are made by a small core team. Vulnerability reports are welcomed from anyone, with named credit; patches from external parties are not. We are deploying security software with administrator-equivalent privilege scope inside customer accounts. The cathedral model is the appropriate governance for that level of responsibility. It means there is one chain of accountability, one signing identity per release, one set of decisions about what runs with that privilege. This article is about strengthening the next layer of that posture: supply-chain security. What's not changingBefore 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. What's changing, and what it eliminatesToday, version specifications exist where correctness or compatibility demands them. Direct dependencies are range-pinned. Security-sensitive libraries — requests, urllib3, and others on user-input paths — are tightly bounded with explicit upper limits. What we do not yet have is uniform coverage: full lock files that pin every transitive dependency with a cryptographic hash, a machine-readable bill of materials per release, and a published vulnerability-response timeline. This initiative extends the existing discipline to every single external library, transitives included, and adds the artefacts and timelines enterprise security teams expect. After it lands:
Where we land on the frameworksWe are aiming for a defensible, framework-anchored posture — using the language enterprise FOSS intake teams already speak:
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. On the question of a paid third-party auditWe 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. How this rolls outGradually, 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. In summaryOpen-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]. AWS Security Hub: What Changed and What You Should Do  If you've logged into the AWS console recently, you may have noticed something odd: there's now both "Security Hub" and "Security Hub CSPM" in the menu. What's going on? AWS has restructured Security Hub in a way that we find unnecessarily confusing. This article explains what changed, why it matters, and what OpenSecOps customers should do about it. The short version: Keep using Security Hub CSPM. Don't enable the "new" Security Hub. Your autoremediation continues working exactly as before. The Great RenamingIn June 2025, AWS made the following changes:  You read that correctly. AWS took the name "Security Hub" away from the existing service and gave it to a brand new, completely different service. The original Security Hub was renamed to "Security Hub CSPM" (Cloud Security Posture Management). We'll say it plainly: this naming decision creates unnecessary confusion. Customers searching for documentation, following tutorials, or talking to AWS support now have to constantly clarify which Security Hub they mean. Why Two Services?The difference is technical but important:  ASFF is the format AWS created years ago for security findings. It works, it's mature, and it's what all existing automation is built on. OCSF is a newer industry standard backed by AWS and over 100 security vendors. It promises better interoperability across cloud platforms and security tools. The catch: these formats are not compatible. Automation built for ASFF does not work with OCSF. What This Means for You OpenSecOps SOAR processes security findings in ASFF format from Security Hub CSPM:  This is how your failed controls get automatically fixed. This is how incidents get created and escalated. This is how your weekly AI security report gets generated. If you enable the new Security Hub, it generates findings in OCSF format. Your SOAR won't process them - it's expecting ASFF. You'll end up with:
Our RecommendationDon't enable the new Security Hub. Your current setup provides everything you need:
The new Security Hub adds AI-powered risk prioritization and enhanced analytics. But you already have intelligent prioritization through SOAR's processing pipeline. The practical benefit is minimal for customers with mature automation. Common Questions"Should I worry that we're using the 'old' service?" No. Security Hub CSPM is fully supported and receiving updates. AWS has announced no deprecation timeline. "Will AWS eventually discontinue CSPM?" Unknown. If they do, there will be a migration path and we'll guide you through it. "What if I already enabled the new Security Hub?" You can disable it or simply ignore its findings. Your SOAR continues processing CSPM findings regardless. "Is AWS pushing customers toward the new service?" The console does prompt you to enable it. You can decline. If AWS representatives ask why, explain that you have ASFF-based automation that would break. The Future: OCSF Support We recognize that OCSF is becoming the industry standard. While ASFF has served AWS customers well, OCSF offers broader interoperability - and AWS clearly sees it as the future. We are evaluating OCSF support for a future release of OpenSecOps SOAR. When we implement it:
We'll announce OCSF support when it's ready. Until then, Security Hub CSPM remains the correct choice. What To Do Now SummaryAWS renamed Security Hub to Security Hub CSPM and launched a new, incompatible service called Security Hub. The naming is confusing, but the action is simple: stick with what you have.
Your OpenSecOps automation runs on ASFF. The new Security Hub speaks OCSF. They don't talk to each other. When OCSF support matters, we'll build it. Until then, your security posture is exactly where it should be. Peter Bengtson OpenSecOps Jeff Barr, Vice President & Chief Evangelist at Amazon Web Services, has mentioned OpenSecOps Foundation & SOAR on LinkedIn: Full post and comments here:   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  Embracing Transparency and CommunityToday, we're excited to announce a significant milestone for OpenSecOps: the complete transition of our platform to open source. This decision represents our commitment to transparency, community collaboration, and ensuring the long-term viability of these security tools. Why Open Source?Our journey towards open source began with several components already freely available on GitHub. The success of these tools – like our serverless log aggregation system and SSO configuration utilities – showed us the value of community engagement and transparent development. As economic conditions shifted in 2024, particularly affecting the specialised technical consulting market, we faced important decisions about the future of these security-critical platforms. After careful consideration of what would best serve our existing customers and the broader AWS security community, the path forward became clear: complete open source was the answer. Ensuring Continuity Through TransparencyThe 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:
Security-First Open SourceUnlike many open source projects that prioritise rapid feature development, our approach is distinctly security-focused:
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. What's Now Available Our complete platform is now open source, including:
How to Get StartedGetting started with OpenSecOps is straightforward:
Looking Forward Going open source is just the beginning. We're committed to:
In ConclusionThe 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.  Do you remember the Log4j exploit? In late 2021, this vulnerability sent shockwaves through the IT industry, leaving organisations scrambling to assess their risk and implement protective measures. For weeks, IT security departments worked overtime, issuing directives and diverting significant resources to address the threat. The atmosphere was tense, with many companies operating in a state of heightened alert. This scenario, unfortunately, is not uncommon in the world of cybersecurity. New vulnerabilities emerge regularly, often catching even the most prepared organisations off guard. The traditional response involves a flurry of activity: emergency meetings, hasty patch deployments, and anxious monitoring of systems. It's a reactive approach that, while necessary in many cases, can be both costly and disruptive. But what if there were a way to stay ahead of these threats without the panic? Enter OpenSecOps SOAR. This system leverages the power of AWS's security suite to provide a proactive defence against even the most novel threats. In the case of the Log4j vulnerability, AWS updated its GuardDuty detectors within a remarkably short timeframe. For organisations using OpenSecOps SOAR, this meant immediate protection without any manual intervention. The system would have automatically detected any exploit attempts, snapshotted affected servers for forensic analysis, and terminated compromised instances to prevent further damage. This automated response isn't just about speed; it's about consistency and comprehensiveness. While human teams might miss indicators during a crisis, OpenSecOps SOAR's integration with AWS's machine learning-driven security tools ensures that no potential threat goes unnoticed. Moreover, the system's ability to snapshot and terminate compromised servers in parallel is a game-changer. In a large-scale attack, this capability can significantly reduce the attack surface in minutes, a feat that would be impossible for human teams to achieve. The benefits extend beyond immediate threat response. By automating these critical security functions, OpenSecOps SOAR frees up security personnel to focus on strategic initiatives rather than firefighting. It also provides peace of mind, knowing that your systems are protected against threats you haven't even anticipated yet. This approach to security aligns perfectly with the evolving nature of cyber threats. As attacks become more sophisticated and frequent, relying solely on human intervention becomes increasingly untenable. OpenSecOps SOAR, built on the robust foundation of AWS's security services, offers a way to stay ahead of the curve. In essence, OpenSecOps SOAR transforms your security posture from reactive to proactive. It's not just about responding to threats; it's about being prepared for them before they even materialise. In a world where the next big vulnerability is always just around the corner, this level of readiness isn't just beneficial – it's essential.  |
RSS Feed