1. Packer 1.16 puts SLSA provenance on the golden image — opt-in, and on a ladder

InfoQ · September 8, 2026

The machine image has been the quiet gap in most supply-chain programmes. Organisations that can produce an SBOM for every container and an attestation for every application build still hand their platform teams AMIs and QCOW2 files whose origin is documented in a wiki page. Packer v1.16.0 closes that gap with a provenance post-processor — and the fact that it is a post-processor rather than a change to the builders is the first thing worth noting, because it means the feature attaches to existing templates instead of requiring them to be rewritten. The post-processor emits in-toto statements carrying the SLSA Provenance v1 predicate, which is the right format to have picked: it is the predicate that downstream verifiers already understand, so the output is consumable by policy engines that were never taught anything about Packer.

Two design decisions deserve to be read carefully before anyone plans a rollout. The first is that verification is opt-in and not on by default. The release documentation is explicit: “All new functionality is opt-in, and existing Packer templates require no changes to build under v1.16.0.” That is a sensible compatibility promise and a real operational caveat — upgrading Packer does not give you provenance, and it certainly does not give you enforcement. Somebody has to configure the post-processor, and somebody else has to make consuming systems actually check the attestation, which is where most provenance programmes quietly stall. The second is that SLSA level here is a three-tier ladder rather than a single target. L1 is the provenance post-processor with optional signing. L2 is Packer running on a CI platform with keyless signing and upload to a Rekor transparency log. L3 requires generation to be split out of the build job entirely, using external tooling Packer does not ship. Packer supplies the machinery for L1 and L2; L3 remains an integration exercise. If your compliance narrative currently says “we are SLSA-aligned,” this release is a good prompt to say which rung.

The signing options are broader than most teams will need and exactly broad enough to fit into an existing key story: unsigned JSON for teams that want the metadata before they want the cryptography; local PEM keys; cloud KMS or HashiCorp Vault for anyone with a managed key hierarchy; and Sigstore Fulcio keyless signing with a Rekor transparency-log entry for CI-driven builds. The artifact-binding detail is the one platform engineers should flag in review, because it differs by target: local artifacts such as QCOW2 and VHD bind to a SHA-256 digest, while cloud artifacts such as AMIs bind to a canonical identity record of builder and artifact IDs. Those are not equivalent guarantees. A digest is a statement about bytes; an identity record is a statement about a registry entry that a sufficiently privileged account can replace. Anyone building verification policy on top of this should decide now what an AMI attestation is actually asserting in their threat model, and whether re-verification at deploy time is required.

The release also carries unrelated HCL2 improvements that will matter more to daily use than the provenance work: a continue_on_error meta-argument, optional() support in object type constraints, and the new functions rfc3339_parse() and unix_timestamp_parse(). A reference CI workflow implementing the L2 pattern ships with the release, which is the fastest route to a working example. The practical recommendation: turn the post-processor on for one image family this quarter at L1, get the attestations flowing and stored, and only then argue about signing mode — the hard part of this work has never been generating provenance, it has been having somewhere to put it and something that reads it.

Sources: https://www.infoq.com/news/2026/09/hashicorp-packer-verification/

2. Open by default after AI: the UK guidance is clear, the enforcement is not

OpenSSF · September 10, 2026

The document under discussion is AI, Open Code and Vulnerability Risk in the Public Sector, published on 14 May 2026 jointly by the UK Government Digital Service and the Department for Science, Innovation and Technology. Its central move is one that most internal security policies get wrong: it mandates that publicly-funded code stays open by default and explicitly prohibits closing a repository to compensate for poor security hygiene. That prohibition is the whole argument. The instinctive response to “AI makes it easier to find bugs in our published code” is to publish less code, and the guidance names that response as a failure of remediation capability rather than a security control. Sal Kimmich of OpenUK, writing with Simon John of TuxCare, puts the underlying claim plainly: AI does not create vulnerabilities, it accelerates the discovery of vulnerabilities that already exist. Closure changes who finds them first and nothing else.

The four binding recommendations are worth lifting directly into an internal standard, because they are unusually operational for government guidance. Meet a minimum bar before publishing: named ownership, a disclosure route, no committed secrets, automated vulnerability management and patch SLAs. Maintain the open-by-default posture thereafter. Where closure is genuinely necessary, require an explicit threat model with named attackers and a time-bound exception — not a general appeal to risk. And invest in remediation speed rather than opacity. The threat-model-with-an-expiry-date requirement is the part most organisations could adopt unchanged; it converts “we made this private for security reasons” from an unfalsifiable statement into a dated document with a name on it.

The thesis of the piece, though, is the enforcement gap, and it is the reason to read it rather than just the source guidance. GDS standards apply across government, but enforcement is inconsistent, and the authors cite NHS England breaching existing open source policy despite having that policy in place as the demonstration. Their conclusion is the one that should interest anyone building supply-chain tooling: durable enforcement requires machine-readable, operational evidence about a project’s actual security posture, not paper attestations produced at review time. That is a statement about tooling, not about policy, and it points at the same primitives the rest of this issue is circling — provenance that a verifier reads, SBOMs in machine-readable formats, baseline checks that run rather than get filled in. Terence Eden, formerly Head of Open Technology at NHSX, appears in the commentary around it.

The timing gives this more weight than a policy essay usually carries. CRA Article 14 reporting obligations commenced on 11 September 2026, two days after publication, requiring manufacturers to notify ENISA and national CSIRTs within 24 hours for an early warning and 72 hours for full notification of actively exploited vulnerabilities; the main CRA provisions follow on 11 December 2027, and Annex I Part II mandates SBOMs in machine-readable formats. The surrounding standards landscape named in the piece — NIST SP 800-218 (SSDF), NIS2, the UK Cyber Security and Resilience Bill (HL Bill 32) with a consultation scheduled for 2026, the DSIT Software Security Code of Practice and the OpenSSF Security Baseline — is converging on the same demand from four directions at once. For a UK public-sector supplier the practical read is that the open-by-default requirement and the CRA evidence requirements are the same engineering programme: know what you ship, know who owns it, have a route for someone to tell you it is broken, and be able to prove the fix shipped.

Sources: https://openssf.org/blog/2026/09/10/open-by-default-after-ai-the-gds-guidance-and-the-enforcement-question/

3. The OSPO becomes the CRA function — and two thirds of the market has not started

Linux Foundation · September 9, 2026

Two dates frame this one: 11 September 2026 for reporting obligations covering actively exploited vulnerabilities and severe incidents, and December 2027 for full CRA applicability. The readiness numbers against those dates are the reason to circulate this internally. OpenSSF’s 2026 CRA Awareness and Readiness Report found 66% of respondents had little or no familiarity with the regulation, and among those who were familiar, 41% had not determined whether it applied to them at all. That second figure is the more troubling one, because applicability is the cheapest question to answer and the one that gates everything else. ENISA’s SBOM Adoption State of Play 2026 supplies the matching capability picture: 78% of organisations have started SBOM adoption, and 9% have reached mature, fully automated implementation. Between those two numbers sits the actual 2027 problem.

The CRA’s three actor roles are the structure to reason from, and most engineering organisations occupy more than one. A manufacturer places a product with digital elements on the market and carries the full obligation set. An open source software steward is a new category with a lighter but real duty — under Article 24, reporting actively exploited vulnerabilities in the projects it stewards. A contributor, meaning an individual maintainer, is largely out of scope. The interesting work is in the middle: an organisation that publishes projects, funds maintainers and depends on hundreds of upstreams has to decide, project by project, which of those it actually stewards. Nokia’s OSPO is running exactly that as one of three CRA workstreams — the others being automating open source due diligence and coordinating vulnerability fixes with upstream communities — and identifying stewarded projects is the one nobody can outsource.

The Linux Foundation’s 2025 State of OSPOs survey of 116 organisations explains why the OSPO is where this lands: 92% involve the OSPO in open source security, 42% say it makes security-risk decisions and 50% say it advises the responsible teams. That is a function with authority over exactly the surface the CRA regulates and, in most organisations, a headcount in the low single digits. The CRA’s SBOM expectations make the resourcing question sharper than a single-artifact reading suggests: component information has to connect across product portfolios and lifecycles, stay accessible, and identify ownership, released versions, internal modifications and support periods. That is a data-management programme with a retention policy, not a build-time file. The tooling named — OpenSSF Scorecard, the Open Source Project Security Baseline, ORBIT, the OpenChain Project and the TODO Group — covers the measurement and the community process but not the portfolio-wide inventory, which remains the gap most organisations will have to fill themselves.

On whether agents help, Cornelius Schumacher of DB Systel gives the correctly bounded answer: “Agentic workflows can help OSPOs when sufficient automation is already in place and reliable, high-quality data is available through APIs.” Which is to say they accelerate a functioning process and do nothing for an absent one — the same conclusion the disaster-recovery and provenance stories in this issue arrive at from different directions. If your organisation has not answered the applicability question, that is this quarter’s work, and it is a half-day exercise for a product counsel and an engineering lead, not a programme.

Sources: https://www.linuxfoundation.org/blog/how-ospos-are-preparing-organizations-for-the-eu-cyber-resilience-act

4. MCP access policy: the measured number is 36.5%, not one in five

The New Stack · September 10, 2026 · Contributed by a CloudBolt executive

Start with the research that has a methodology. MCPTox is a benchmark that tested 45 live MCP servers against 20 models and recorded a 36.5% average attack success rate, rising to 72.8% against the worst-performing model. That is the figure to take into an architecture review, because it is reproducible, third-party and scoped: it says that a meaningfully large fraction of tool-invocation attempts against real deployed servers succeed in doing something the operator did not intend, and that model choice moves the number by a factor of two. It sits alongside an Invariant Labs study from May 2025 on MCP tool-poisoning, which established the mechanism — instructions smuggled through tool descriptions and results rather than through the user’s prompt.

The headline claim attached to this article deserves a correction rather than an amplification. The assertion that “more than 20 percent of the MCP-related access policies we reviewed were either broken or missing entirely” is CloudBolt’s own observation, offered by Chief Customer Officer Shawn Petty from policies the company encountered “while setting up our own MCP integrations across customer and prospect environments.” There is no published denominator, no sampling method and no date range. It is a practitioner impression from a vendor with a product in the space, and it should be read as one — useful as a prompt to go and look at your own policies, not as a market statistic. The defects it counts are at least concrete and worth using as a checklist: absent scoping, no OAuth, static tokens with no rotation schedule, absent logging.

The credential-posture figures in the piece are the ones that actually explain the benchmark result. 88% of MCP servers require credentials but only 8.5% use OAuth; over 50% run on static API keys or personal access tokens. (The source for that second figure is not named in the article, so treat it as directional.) Add the finding that close to 50% of enterprise AI activity runs through personal rather than corporate accounts and the shape of the problem is clear enough without any survey: a large population of long-lived, broadly-scoped, personally-held credentials, attached to servers that accept instructions from untrusted content, with no logging on the path. The MCP specification revision dated 2026-07-28 is the current authorization baseline and it is adequate; the deployment base has simply not moved to it. One concrete vulnerability is named — CVE-2026-20205 in Splunk MCP Server version 1.0.3 — which is useful mostly as proof that these are ordinary software components with ordinary advisories, and should be inventoried and patched like any other dependency.

The action items are unglamorous and entirely within reach: inventory the MCP servers your engineers actually have configured, including the ones running on personal accounts; move anything that holds a static token onto scoped OAuth against the current spec revision, or take it out of the corporate path; give every server an identity and a log; and test your own deployment against the tool-poisoning pattern rather than assuming your model will refuse. The benchmark says roughly one attempt in three succeeds somewhere in the population. There is no reason to believe your servers are the exception.

Sources: https://thenewstack.io/mcp-vibe-coding-security/

5. Four years of live API keys, read out of the Wayback Machine

The Register · September 9, 2026

This is the cheapest attack in the issue and the one with the largest blast radius. Independent security researcher Scott Helme retrieved historical JavaScript bundles for Manchester Airports Group — operator of Manchester, Stansted and East Midlands airports — from the Internet Archive’s Wayback Machine, and read API credentials out of the client-side code. No authentication was defeated and nothing was exploited. The keys granted read/write API access to Iterable, MAG’s marketing automation platform, covering customer profiles, parking and lounge bookings and Fast Track purchases — including endpoints capable of deleting customer records and lists and rewriting profiles. The exposure window runs from June 2022 to August 2026, roughly four years. Helme’s summary is the line to quote at anyone who thinks front-end secrets are a theoretical problem: “For four whole years, the capability to delete Manchester Airports Group’s database was a view-source away.”

Two things are worth separating carefully here. The first is that the rotation status is unresolved. The public record does not say when or whether those credentials were revoked or rotated, and nobody should assume they were. If you are assessing third-party risk against MAG or Iterable, that is an open question to ask rather than a closed one to note. The second is that this is adjacent to, but distinct from, the breach MAG has been dealing with publicly: the extortion group FulcrumSec released stolen data on 2 September 2026 after MAG declined to pay, affecting roughly 8.8 million customer records. No causal link between the exposed keys and that incident has been established. MAG declined to comment on Helme’s findings and has publicly characterised the breach as “sophisticated” and “a hack, not a lapse”; the ICO and the National Crime Agency are involved. No CVE IDs are associated with any of it, which is itself the point — there was no vulnerability to assign one to.

The engineering lesson generalises immediately and most organisations are exposed to it. Secret scanning that runs against your source repository does not see this. The credential in question was almost certainly never committed as a literal; it was injected at build time into a bundle, which is exactly the pattern every front-end build system encourages, and the bundle was then served publicly and archived by third parties who do not have a deletion workflow you can invoke. That last property is the one that changes the remediation calculus: a secret that reached a public bundle is not recoverable by rotation alone within the window it was live, because copies exist outside your control, and the only useful question is how quickly you noticed. Four years is the answer here.

Three controls follow, and none of them are expensive. Scan your built artifacts, not just your source — run the same secret detection against the output of your web build in CI, and fail the pipeline, because that is the only place this class of mistake is visible. Give every third-party API key the narrowest scope the vendor supports; a marketing platform key that can delete records is a configuration choice somebody made, and read-only plus server-side proxying for anything that mutates is almost always available. And periodically diff your own public bundles against archived copies — if a researcher can enumerate four years of your JavaScript in an afternoon, so can you, and it is a far better way to find out.

Sources: https://www.theregister.com/cyber-crime/2026/09/09/security-boffin-claims-airport-group-left-api-keys-in-client-side-javascript-for-four-years/5295192

6. kubectl is a public client: the OIDC configuration most clusters get wrong

CNCF · September 8, 2026

The argument is narrow, correct and immediately actionable. kubectl is a native command-line application, so it must be registered with your identity provider as a public OIDC client using PKCE, never as a confidential client with a secret. Kolawole Olowoporoku, CNCF Ambassador and Senior Platform Engineer, states the reason in one sentence: “A secret that has to be distributed to every client that uses it isn’t functioning as a secret.” OAuth 2.1 settled this for native and CLI applications; a great many clusters were configured before anyone noticed, and the client secret now lives in a wiki page, an onboarding script and several hundred laptops.

PKCE with the S256 method is the mechanism that makes the public-client model safe. It prevents authorization-code interception by forcing the client to prove possession of a locally generated verifier at token exchange, which removes the need for a pre-shared secret entirely rather than replacing it with a weaker one. The Keycloak configuration is concrete enough to copy: client authentication Off, Require PKCE On (S256), standard flow enabled, direct access grants disabled, and redirect URIs restricted to loopback only — http://127.0.0.1:* and http://localhost:*. Disabling direct access grants is the item most likely to be skipped and the one that matters: it removes the password-grant path that turns an identity provider back into a credential store. A Group Membership mapper with the token claim name groups is configured so that Kubernetes RBAC binds to group membership rather than to individual subjects.

On the cluster side, the kube-apiserver validates tokens directly against the IdP’s public signing keys — there is no callback, no introspection endpoint and no shared secret in the control plane. The flags are --oidc-issuer-url, --oidc-client-id, --oidc-username-claim, --oidc-groups-claim and --oidc-ca-file. Client tooling is kubelogin (kubectl oidc-login), the exec-credential plugin maintained by int128, which means the change is invisible to users beyond a browser prompt on first use.

The four risks of the status quo are the business case, and they are worth reading as a list of things your incident response currently cannot do. Shared static credentials sit in kubeconfig files with no expiry. Revocation requires finding every copy of a file, which in practice means rotating the cluster CA and hoping. Individual identity disappears from the audit log when everyone authenticates as the same cluster-admin certificate — the log records that the change happened and cannot say who made it. And rotation requires a coordinated configuration push to every machine, which is why nobody does it. Any one of those is a finding in an audit; all four together describe the default state of a cluster set up with certificates in a hurry three years ago. This is a half-day change for most platform teams and it removes an entire category of question from the next assessment.

Sources: https://www.cncf.io/blog/2026/09/08/kubernetes-access-via-an-identity-provider-public-client-not-confidential/

7. Three reproducible ways your Kubernetes disaster recovery is not what you think

CNCF · September 10, 2026

This is the most useful piece of engineering writing in the issue because every claim in it was produced by a run rather than by an argument. Saiyam Pathak and Saloni Narang, both CNCF Ambassadors, built three reproducible failure scenarios against a PostgreSQL workload with a known four-row deterministic dataset and captured the terminal output from real runs. The framing sentence is the one to put in front of whoever owns your backup dashboard: “A backup phase of Completed means the backup operation completed. It does not prove the application will start, contain the expected data, or serve traffic.”

Scenario 1 — backup status lies. A Velero backup reporting phase Completed establishes only that the backup operation finished. The authors treated a backup as valid only after confirming that 47,989,888 bytes of volume data had actually landed in external storage via Velero’s data mover. That is the correct validation and almost nobody performs it, because the green tile in the dashboard is reading the operation status rather than the payload. If your monitoring alerts on backup failure but not on backup byte count, you are monitoring a job scheduler.

Scenario 2 — GitOps is not a backup. Re-syncing from Git after a namespace loss recreated the StatefulSet, recreated the Service, and provisioned a brand new empty volume, because Git only ever held declarations. This is the failure mode most likely to be live in a well-run organisation right now, precisely because a mature GitOps practice feels like it covers recovery. It covers reconstitution of intent. It does not contain a single byte of your data, and the more automated the reconciliation, the faster it will confidently rebuild an empty database over the top of the problem.

Scenario 3 — multi-volume consistency. Snapshotting two volumes independently produced 25 orphaned payment records with no matching orders — a silent, application-level corruption that every status indicator in the stack reports as success. Using the VolumeGroupSnapshot API, GA in Kubernetes 1.36, produced matching counts and zero loss. The production caveat is important and the authors state it themselves: the lab used the CSI hostpath test driver, and as of mid-2026 production CSI drivers largely lack group snapshot support, so the fix for scenario 3 is not yet broadly available. Knowing that you have the exposure and cannot yet close it is still considerably better than not knowing.

Measured recovery time was 4 minutes from production loss to validated recovery on the first attempt and 2 minutes on a rehearsed rerun — which is both encouraging and the strongest available argument for rehearsing. The three ecosystem gaps the authors name are the ones to carry into platform planning: there is no cross-cluster failover contract, no standard definition of a recovery unit, and backup success is monitored as if it were recovery proof. The whole lab is reproducible from a public repository, which means this can be a team exercise rather than a reading assignment, and that is how it should be used.

Sources: https://www.cncf.io/blog/2026/09/10/kubernetes-disaster-recovery-guidance-from-three-reproducible-failure-scenarios/

8. Microsoft makes Rust a Tier 1 language — a policy decision with a toolchain attached

The Register · September 11, 2026

This is a policy designation rather than a product release, and that is what makes it consequential. Rust now sits alongside C++, C# and TypeScript as a Tier 1 internal language at Microsoft, which means full support across the company’s SDLC and internal tooling — build systems, security review, dependency management, the whole apparatus that determines whether a language is genuinely usable inside a large organisation or merely permitted. Victor Ciura, principal engineer on Microsoft’s Rust tooling team, announced it in a RustConf 2026 keynote, describing Rust as a “Tier One language at Microsoft… sits among C++, C#.”

The deployment evidence behind the designation is substantial enough that the announcement reads as ratification rather than ambition. Rust is present in over 100 Microsoft project repositories. It is in production in Microsoft 365 core services — Outlook, Word, Excel, OneDrive and SharePoint — and in the company’s AI assistant stack. Microsoft has built Oxidizer, an internal crate library for scalable Rust services, which is the sort of investment that only happens after the language has stopped being an experiment. The most technically interesting item is rustc_codegen_utc, a custom Rust compiler backend that wires rustc into the MSVC toolchain to produce native Windows binaries from a code generation platform shared with C++. If that ships, it addresses the practical objection that has kept Rust out of many Windows codebases — that mixing Rust and C++ means mixing toolchains, debuggers and optimisation behaviour.

The justification is the memory-safety argument at its most familiar and most load-bearing: roughly 70% of Windows CVEs are memory-safety issues, a figure attributed to Azure CTO Mark Russinovich in a 2025 RustConf keynote. The scale context supplied alongside it — 974 CVEs in a recent Patch Tuesday release — is what turns a percentage into a programme. Seventy per cent of a number that large is not a class of bug you review your way out of; it is a class of bug you change languages to eliminate.

For everyone else, the useful read is about what Tier 1 status actually costs, because that is the transferable part. The designation implies the tooling exists: dependency policy for crates, a security review process that understands unsafe, build infrastructure, debugger support, and people who can review the output. Organisations adopting Rust for the memory-safety argument alone frequently discover that the language was the easy part and the supporting apparatus was the project. Microsoft has spent years building that apparatus and is now saying so publicly, which makes this a reasonable reference point for anyone making the same case internally — and a reminder that “we allow Rust” and “we support Rust” are very different commitments.

Sources: https://www.theregister.com/devops/2026/09/11/microsoft-anoints-rust-as-a-tier-1-internal-language/5295732