Cybersecurity briefing
/
The Software Supply Chain Has a Change Management Problem
Bloom Security's SlugFest disclosure shows why repository changes need security review, and how AI coding tools and release workflows raise the stakes.
/
AUTHOR
Jeff Dyer
/
SHARE THIS ARTICLE
Overview
A software repository can change hands while a publishing system continues to trust its old name. Bloom Security's October 13 disclosure of SlugFest exposed that gap in npm's trusted publishing process, showing how a routine repository change could become a route to unauthorized releases. For organizations adopting AI coding tools, the incident raises a broader operational question: which security decisions are reviewed again when the software supply chain changes?
The answer matters on both sides of a release. Maintainers control who may publish a package. Development teams decide which packages may enter their applications. AI can accelerate the second process without improving the evidence behind either decision.
A trusted name can point somewhere else
According to Bloom, the vulnerable configuration identified an authorized repository by its reusable owner-and-name address before the first successful publish established its permanent identity. An attacker who claimed an abandoned address could satisfy that configuration. The researchers demonstrated publishing between repositories they controlled; the disclosure does not establish that every exposed package was maliciously released.
GitHub's October 2 change makes unvalidated configurations expire after 48 hours. A successful first publish validates the configuration, while changing the repository or project identity requires a new trust relationship. The fix predates the research disclosure.
Trusted publishing remains a useful security measure. npm documents how it uses OpenID Connect to authenticate approved CI/CD workflows without relying on long-lived publishing tokens. The incident shows why removing a reusable credential still leaves another obligation: maintaining the relationship between an authorization and the entity it was intended to trust.
Repository administration belongs in the release process
Renaming, transferring or retiring a repository can look like administrative housekeeping. If a package registry, deployment job or other service relies on that repository, the change also affects a security dependency. A complete change record should identify those relationships and assign someone to verify them.
That review is different from scanning application code. A scanner may find a vulnerable dependency or an exposed secret without identifying every stale publishing relationship. A green dashboard cannot answer a question its underlying tests never asked. Teams need explicit requirements for repository ownership changes, publishing workflows and retirement, alongside their vulnerability checks.
Consider a hypothetical software team consolidating several projects after an acquisition. Engineers move repositories, rename organizations and retire duplicate workflows. The application may pass its normal tests while a registry still contains an obsolete trust configuration. The missing control is a required ownership review tied to the migration, with evidence that the old authorization was removed or replaced.
Security requirements need a path into engineering work
DevSecOps orchestration platforms connect those requirements to development workflows. Wabbi, a continuous security platform in this category, combines application context, customer-defined policies and findings from existing AppSec tools to organize security work. Its secure release management capabilities support policy-based approvals and release gates through configured development integrations.
The organization still defines the requirement and supplies the evidence. A repository migration, for example, could require an accountable owner to review publishing relationships before a release proceeds. Implementing that review depends on the events, integrations and workflow behavior available in the deployment. An orchestration layer does not independently discover or repair npm's trust implementation, and a workflow cannot verify facts it never receives.
The value is continuity. Security requirements stay associated with the application and its release process, with an identifiable owner and a record of exceptions. They are less likely to disappear into a separate checklist when engineers change teams, repositories or delivery tools.
AI changes the pace of dependency decisions
An AI coding assistant can introduce a library while completing a seemingly small task. The reviewer may concentrate on whether the generated code works and overlook the additional software now running in the development environment or build. Dependency review therefore needs to cover changes made by automation as well as changes proposed directly by developers.
Practical controls include reviewing newly introduced packages and versions, restricting unnecessary installation scripts, separating development credentials from publishing authority and retaining a record of what entered the build. Each control addresses a different point in the chain. A lockfile can make dependency resolution reproducible without establishing that the selected version is trustworthy.
Approval should also match the application's consequences. An internal prototype and a payment service need different release criteria. Exceptions can be reasonable when their scope, owner, supporting evidence and expiration are recorded. Treating every exception as permanent gradually turns the release policy into a description of what teams used to require.
The immediate work is concrete: review publishing relationships, include repository changes in security change management and make automated dependency additions visible in engineering review. Then test whether the process catches a deliberately incomplete change. The measure of a release control is whether it stops or escalates the right decision with usable evidence, not whether a policy document says the review should occur.
