This week at a glance
Open Source Summit Europe in Prague set the agenda this week, and the theme was who pays to fix open source, and how they prove the fix. FINOS launched the Open Source Enterprise Resiliency Alliance (OSERA) with six premier members, among them Deutsche Bank, Goldman Sachs, Morgan Stanley, NatWest and Royal Bank of Canada. The banks are tired of building the same patches separately; the release says one in five financial institutions keeps private forks of the same projects. In about three weeks the alliance published v0.1 of a patching and attestation standard and delivered attested updates for more than 50 Spring and Java projects. It is aiming for at least 80 patches a month through the end of the year. The OpenSSF added members including JetBrains, published CRA readiness guides, and showed Ericsson sending more than 1,400 fixes upstream instead of keeping private forks.
The second thread is SBOMs that no longer describe what ships. TechTarget’s report from Prague counts 1,111 commits tagged Assisted-by in Linux 7.2, against 31 in 7.0. Speakers warned that an agent can paste old, vulnerable open-source code into an application without it ever appearing in the SBOM, and that slopsquatted packages get listed as if they were legitimate. CRA vulnerability reporting has been in force since September, and SBOMs become mandatory in December 2027. The OpenChain Automotive SBOM Framework 1.0 gives car makers and suppliers one SBOM format to exchange. A CSO Online opinion piece argues that enterprises should link their SBOMs, cryptography BOMs and AI BOMs in one evidence graph instead of running six programs.
The third thread is the comprehension gap. An Undo-commissioned survey of 300 engineering leaders found teams spending 16.9 hours a week debugging and 9.8 producing code, with 35% of generated code reaching production before anyone fully understands it. Stack Overflow’s 2026 survey of 30,903 developers found only 6.6% trust AI with important decisions. OpenSSH 10.6 enabled the hybrid ssh-mldsa44-ed25519 signature, and its maintainers said they will release more often after a flood of security reports, many of them found with AI. On the controls side, a CNCF post argues agents should never get root and should instead propose the next system state through the normal pipeline. NIST’s NCCoE says its next DevSecOps build will demonstrate agentic AI writing, building and testing code.
On our watch list
- OSERA’s first end-to-end platform release in November. FINOS plans it for the Open Source in Finance Forum in New York, together with a per-project sponsorship model. Watch whether it hits the 80-patches-a-month target and whether banks outside the founding group sign up.
- Whether OSERA’s attestation standard spreads beyond finance. Version 0.1 sets what a fix must meet before it is trusted. Watch for other regulated sectors, or the OpenSSF, adopting or aligning with it.
- How SBOM tooling answers agent-inserted code. Static SBOMs miss code an agent copies in. Watch for continuous or build-time SBOM generation becoming the default, and for CRA guidance that addresses AI-assisted development directly.
- NIST NCCoE DevSecOps comment deadline, 9 November. The webinar on 28 October covers Build 3, which will use agentic AI to develop, build and test code, and joint work on AI agent identity and authorisation. Watch what controls the reference build puts around the agent.
- Post-quantum SSH in the wild. OpenSSH 10.6 enables
ssh-mldsa44-ed25519. Watch for distributions shipping 10.6, for the hybrid algorithm becoming a default, and for incompatibilities with old experimental keys.
- OpenSSH’s faster release cadence. The maintainers tied it to a surge of AI-found security reports. Watch how many fixes the next few point releases carry, and whether other core projects follow.
- Where open-source projects draw the AI line. COSMIC now requires contributors to declare no AI-generated content; a GNOME developer is pushing to accept AI-found bug reports. Watch for KDE and GNOME formal decisions and for policies that split “AI found it” from “AI wrote it”.
- AGNTCon + MCPCon North America, 22–23 October in San Jose. The Agentic AI Foundation now has 270 members. Watch for agent authorisation and tool-call security on the agenda.
- Open Source SecurityCon North America, 9 November in Salt Lake City. Watch for the first CRA reporting experience from manufacturers and for BOMHort and other SBOM governance tools maturing in the OpenSSF sandbox.
- Whether review time becomes a tracked delivery metric. The Undo survey has 79% of leaders saying agents write code faster with no faster releases. Watch for teams measuring time-to-understand and review load alongside DORA metrics.
This week’s topic map: open-source supply chain at the centre. One cluster holds OSERA, FINOS and the banks funding shared, attested fixes. Another holds the EU Cyber Resilience Act, SBOMs, AI-inserted code, slopsquatting, OpenChain Automotive and SPDX. A third covers the comprehension gap: AI-generated code, debugging time, developer trust and review. Around them sit the controls (EPSS prioritisation, secrets rotation, propose-not-apply agents, NIST NCCoE) and OpenSSH’s post-quantum signatures.
View interactive topic map →
Article index
Fixing the commons together
Banks pooling the cost of open-source fixes, the OpenSSF adding CRA guidance and members, OSPOs taking on AI governance, and projects drawing lines on AI-written code and AI-found bugs.
SBOMs, the CRA and evidence
AI coding tools are putting code into products that never shows up in the SBOM, just as the CRA makes SBOMs mandatory. Automotive gets a common SBOM framework, and one practitioner argues for a single evidence graph instead of six BOM programs.
Prioritise, contain, bound
Practical controls: rank vulnerabilities by exploitation and reachability, revoke and rotate leaked secrets, and make agents propose changes instead of applying them.
The comprehension gap
Code arrives faster than teams can understand it. Surveys and studies on where the time goes, and what that does to review, debugging and trust.
Agents, teams and the junior pipeline
How teams are reorganising around coding agents, and who learns the craft when agents take the entry-level work.
Detailed write-ups
1. Banks stop paying the “fork tax” alone: OSERA ships attested open-source fixes
Linux Foundation · October 7, 2026
FINOS, the Linux Foundation’s financial-services foundation, announced at Open Source Summit Europe that the Open Source Enterprise Resiliency Alliance (OSERA) is operational. Six premier members fund it; the release names Deutsche Bank, Goldman Sachs, Morgan Stanley, NatWest and Royal Bank of Canada. The problem they want to fix is duplication. Banks running the same open-source projects each build, or pay someone to build, the same patches. Research cited in the release says one in five financial institutions keeps private versions of the same projects, which it calls the “fork tax”.
The alliance has moved quickly. In about three weeks it published version 0.1 of a patching and attestation standard, which sets what a fix must meet before members trust it. It has delivered attested security updates for more than 50 widely used Spring and Java projects, available to members for production use. Vendor maintainers will handle newly disclosed vulnerabilities on managed release lines under a severity-based SLA, with a target of at least 80 patches a month through the end of 2026. RBC helps lead governance of the backporting pipelines. The first end-to-end platform release is planned for the Open Source in Finance Forum in New York in November. Morgan Stanley’s Dov Katz, who chairs the remediation standards working group: “An open, verifiable standard for remediation delivers trust at scale.”
For DevSecOps teams outside finance, two things matter. First, a published attestation standard for backported fixes gives everyone a way to ask a supplier how a patch was built and checked. Second, it treats the long tail of unmaintained release lines as a shared cost instead of each organisation’s private problem. The CRA’s five-year patch duty creates exactly the same pressure for manufacturers. This is the initiative’s own press release, and the funding banks have an obvious interest in the outcome.
Sources: https://www.linuxfoundation.org/press/major-banks-back-osera-to-deliver-industry-wide-remediation-standards-and-fixes-to-secure-open-source-software
2. AI coding tools are putting code into products that the SBOM never sees
TechTarget · October 9, 2026 · CSO Online · October 7, 2026
Bruce Gain’s report from Open Source Summit Europe brings numbers to a problem many teams suspect. A Linux Foundation survey of more than 600 respondents found 94% use or pilot generative AI coding tools, and 48% say the tools have increased their use of open source. In the kernel, Linux 7.2 carried 1,111 commits with an Assisted-by tag, against 31 in Linux 7.0, and added about 600,000 lines from a record 2,652 developers.
Speakers described three ways this breaks SBOMs. An agent can copy old open-source code into an application, CVEs and all, without the component ever being declared. Omdia’s Torsten Volk: “an agent could grab some old open source code with CVEs attached”. Static SBOMs taken at one point in time miss code agents add later. And slopsquatting, where attackers publish packages under names AI models invent, means the SBOM can faithfully list a malicious package that was installed in good faith. Kubermatic’s Mario Fahlandt, a CNCF TOC member, runs a weekly job that scans CNCF projects with 2,500 workers and has stored 16,000 SBOMs: “If we don’t know which packages are inside of our software, we don’t know if there’s a security issue.” CRA vulnerability reporting has applied since September; SBOMs become mandatory under the CRA in December 2027.
A CSO Online opinion piece by HCLTech consultant Sunil Gentyala argues the answer is not more BOM programs. Software, cryptography, AI and emerging authorisation BOMs should keep their native formats (SPDX 3.0.1, CycloneDX 1.7) but be linked in one evidence graph with a common envelope: subject, version, digest, owner, validity and known gaps. He proposes a 90-day pilot on one critical service, comparing what was declared with the released binary and the deployment, and measuring time to find affected deployments rather than the number of SBOM files.
Sources: https://www.techtarget.com/it-infrastructure/news/366651862/AI-coding-tools-run-riot-over-SBOM-controls-as-EU-CRA-looms, https://www.csoonline.com/article/4231283/your-enterprise-doesnt-need-six-bom-programs-it-needs-one-evidence-graph.html
3. OpenSSF adds CRA guidance and members as OSPOs take on AI governance
OpenSSF · October 6, 2026 · Linux Foundation · October 6, 2026
At Community Day Europe the OpenSSF welcomed four new general members: A-Team Systems, Emphere, DACHS IT GmbH and JetBrains. It published a CRA Readiness practitioner’s guide and a CRA Readiness User Journey, plus role-based journeys for developers, security engineers, OSPO leaders and executives. A case study shows Ericsson Software Technology sending more than 1,400 dependency updates and security fixes upstream and retiring its private forks. OpenBao v2.6 shipped, and BOMHort, a Kubernetes-native SBOM visualisation and governance tool, joined the OpenSSF Sandbox. General manager Steve Fernandez: “Securing the open source ecosystem is no longer just about patching isolated vulnerabilities.”
The Linux Foundation’s 2026 State of OSPOs report, released the same day, shows where that work lands inside companies. 53% of large enterprises now have a formally structured OSPO. Of OSPOs involved in AI governance, 79% work on policy, evaluation of open models and datasets, risk and legal review, and 85% are brought in at or before technology selection. Licensing and security vulnerabilities are each managed as AI risks by 65%. 69% of organisations are prototyping or running agentic tools for OSPO work, and 18% already run them in production. The top outcome OSPOs report is software quality, security and compliance (58%).
The Ericsson case and OSERA make the same point from two directions: fixing upstream is cheaper than carrying forks. If your organisation has an OSPO, it is probably already part of AI tool selection, and it is the natural owner of CRA open-source obligations.
Sources: https://openssf.org/press-release/2026/10/06/openssf-shares-expanded-membership-and-new-global-policy-resources-during-community-day-europe/, https://www.linuxfoundation.org/blog/navigating-open-source-governance-in-the-age-of-artificial-intelligence-the-2026-state-of-ospos-and-open-source-management
4. Car makers get one SBOM framework to exchange across the supply chain
Linux Foundation · October 7, 2026
The Linux Foundation released OpenChain Automotive SBOM Framework 1.0, a common approach for creating and sharing SBOMs between automotive suppliers and OEMs. It defines how components and dependencies are structured, which data fields are required and which are recommended, and the criteria an SBOM must meet to count as complete and of adequate quality. It includes usage scenarios for data exchange across the supply chain.
The framework aligns with SPDX (ISO/IEC 5962) rather than replacing it. It comes from the OpenChain Automotive Working Group, chaired by Masato Endo, with participants including Toyota, Nissan, Volvo Cars and Hitachi Solutions. OpenChain general manager Mary Meixia Wang: “This first release provides practical guidance and helps advance more consistent SBOM practices.” The release cites growing regulatory and cybersecurity pressure but does not name specific regulations.
The value is in the quality criteria. Many SBOMs that pass between companies today are technically valid and practically useless, because each party fills different fields. A sector-wide definition of a complete SBOM gives suppliers a target and gives OEMs something to reject against. Teams in other industries with long supply chains can borrow the approach.
Sources: https://www.linuxfoundation.org/press/linux-foundation-releases-openchain-automotive-sbom-framework-1.0-for-greater-reliability-and-traceability-in-automotive-software
5. OpenSSH 10.6 turns on a post-quantum signature and speeds up releases
Help Net Security · October 7, 2026
OpenSSH 10.6, released on 6 October, enables the hybrid signature algorithm ssh-mldsa44-ed25519, which pairs the post-quantum ML-DSA-44 with Ed25519. Keys generated with the earlier experimental support must be regenerated or removed. ssh and sshd also disable the LZ77 dictionary coder, which makes the Compression option less effective; the maintainers recommend compressing at the application level instead.
Several hardening changes ride along. ssh now refuses usernames containing $ or a backslash when they are passed on the command line, though names set with the User directive in config are exempt. sshd stores GSSAPI credentials only after authentication succeeds, sftp checks paths returned by the server more strictly, and a daylight-saving bug in ssh-keygen that could shift certificate expiry by up to an hour is fixed. GatewayPorts and StreamLocalForwarding are disabled on QNX 6, SCO OpenServer 5 and builds using --disable-fd-passing.
The most telling line is about process. The maintainers will ship releases more often for now, after receiving a large number of security reports, many found by or with AI models, and they warn that others “are likely to be able to discover these bugs too.” For platform teams, that means shorter gaps between OpenSSH updates and less time to roll them out.
Sources: https://www.helpnetsecurity.com/2026/10/07/openssh-10-6-released/
6. The comprehension gap: teams debug for 16.9 hours a week and write code for 9.8
InfoQ · October 7, 2026 · The Register · October 10, 2026
A survey commissioned by Undo, which sells debugging and root-cause tools, and run by Coleman Parkes asked 300 senior engineering leaders responsible for mission-critical software, mostly in C and C++, where their time goes. The average team spends 9.8 hours a week producing code and 16.9 hours debugging it. 35% of AI-generated code reaches production before the team fully understands it. In the past six months, 81% had a production incident or outage, 93% got an incorrect root-cause diagnosis from a hallucinating tool, and 91% had test escapes or serious defects. 79% say agents write code significantly faster, but releases are no faster. Undo’s Greg Law: “while agents are great at writing reams of code quickly, they’re less capable at debugging it”.
Stack Overflow’s 2026 Developer Survey, covered by The Register, shows developers responding the way you would expect. It drew 30,903 responses from 169 countries. About a third of daily AI users spend four or more hours a day with it. Yet only 6.6% trust AI output for important work decisions, 48% trust it only when they can easily verify it, and roughly four in five say source attribution matters when they judge an AI answer.
The Undo numbers come from a vendor whose products address the problem the survey describes, so treat them as direction rather than measurement. They match what the Stack Overflow data and this week’s practitioner essays say: code is cheap, understanding is not. For security that matters directly. Code nobody understands is code nobody can threat-model, and an incident in it starts with a slower diagnosis.
Sources: https://www.infoq.com/news/2026/10/survey-complex-codebases-agents/, https://www.theregister.com/software/2026/10/10/stack-overflow-survey-finds-devs-hooked-on-ai-but-not-totally-sold-on-its-judgment/5301662
7. Severity is not priority: ranking fixes by exploitation and reachability
InfoWorld · October 5, 2026
Sonu Kapoor sets out a model that many teams will recognise and few apply consistently. CVSS describes how bad a vulnerability could be, not whether it is reachable or being exploited. EPSS, maintained by FIRST and updated daily, estimates the probability of exploitation in the next 30 days. CISA KEV records confirmed exploitation. His summary: “Severity is a property of a vulnerability. Priority is a decision about a vulnerability in context.”
He combines them into four lanes. Critical or high findings at or above the 90th EPSS percentile are Fix Now; those below it are Fix Soon. Medium or lower findings above the threshold go to Monitor, the rest to Lower Priority. In one example, a critical CVE sitting near the 77th percentile lands in Fix Soon, while a medium CVE above the 96th percentile is watched more closely. He adds reachability evidence from a Colorado State University study of 30 open-source projects and more than 6,000 scanner-reported CVEs: 43.3% were statically unreachable, rising to 53.1% for TypeScript and JavaScript.
Kapoor implemented this model in CVE Lite CLI, an open-source tool he promotes in the piece. The method stands on its own: whatever scanner you use, adding EPSS, KEV and reachability to the sort order should remove a large share of the backlog from the urgent queue.
Sources: https://www.infoworld.com/article/4229731/knowing-which-vulnerability-to-fix-first.html
8. Don’t give agents root: make them propose the next system state
CNCF · October 8, 2026 · NIST · September 24, 2026
In a CNCF Ambassador post, Mauro Morales, who maintains the Kairos immutable OS project, argues against giving AI agents root or open host access. Instead, an agent inspects the system, records its assessment and opens a pull request that proposes the next state. Base-system changes live in a versioned definition and are consumed as a new image. The proposal goes through the same review, testing, image build, signing and release as a human change. The agent’s identity may propose but may not approve or merge, change the pipeline, sign images or force a machine to take the new state. Agents run in short-lived environments sized to the threat model, and self-healing is limited to pre-authorised restart, replace or rollback. His line: “We do not need to trust the model. We need to trust the boundaries around it.”
NIST’s National Cybersecurity Center of Excellence is heading the same way in its DevSecOps project. It added five items to its live document, including a mapping from the SSDF to DevSecOps practice and an updated AI section. Build 3 will demonstrate agentic AI developing, building and testing code, in joint work with the NCCoE team on AI agent identity and authorisation. A webinar on 28 October covers the plan, and comments are due by 9 November.
The pattern is worth adopting now. Routing agent changes through the same pipeline as human ones gives you review, provenance and signing for free, and separating the right to propose from the right to approve is a control auditors already understand.
Sources: https://www.cncf.io/blog/2026/10/08/dont-give-ai-agents-root-make-them-propose-the-next-system-state/, https://www.nist.gov/news-events/news/2026/09/new-nist-nccoe-resources-devsecops-and-october-28-webinar-agentic-ai
Calls to action
- Count your private forks. List the open-source projects you patch internally instead of upstream. For each, decide whether to contribute the fix upstream, join a shared effort, or accept the cost of carrying it.
- Generate SBOMs at build time, not at release. Agent-inserted code and copied snippets will not show up in an SBOM taken from a manifest. Make sure SBOMs come from the build and are compared with what actually deployed.
- Check new dependencies for slopsquatting. Before an agent-suggested package is installed, confirm it exists with real history and maintainers. Block packages published in the last few days unless a person approves them.
- Add EPSS and KEV to your vulnerability sort order. Rank findings by exploitation likelihood and reachability as well as CVSS, and agree a Fix Now threshold with engineering.
- Revoke, then rotate. When a secret leaks, removing it from the repository is not enough. Revoke it first, rotate it, and scan internal repositories as well as public ones.
- Inventory experimental post-quantum SSH keys. Any keys created with OpenSSH’s earlier experimental post-quantum support must be regenerated or removed before or during the move to 10.6.
- Take root away from agents. For any agent that changes infrastructure, require it to open a pull request through the normal pipeline. Make sure its identity cannot approve, merge or sign.
- Comment on the NIST NCCoE DevSecOps material by 9 November. If you are building controls for agents in your SDLC, this is the reference implementation auditors will read.
|