If you’ve been through the microservices transformation, you’re going to recognise what’s happening with AI right now. Monolithic applications gave way to microservices, and it unlocked scalability, specialisation, and independent deployment across the industry. AI systems are following the exact same path, moving from monolithic LLMs through single-agent tools to coordinated multi-agent AI orchestration.
And this isn’t theoretical hand-waving. 57% of organisations already have AI agents in production. The autonomous agent market is projected to reach $35 billion by 2030. If you’ve worked with microservices, you already understand the core patterns behind multi-agent orchestration—it’s distributed systems thinking applied to AI. By the end of this article, you’ll have a clear framework for deciding whether and when multi-agent orchestration is relevant to what you’re doing.
Multi-agent AI orchestration is the structured coordination of multiple autonomous AI agents working together to achieve complex, shared objectives. Single-agent systems consolidate all logic, context, and capability into one system. Multi-agent distributes specialised responsibilities across coordinated agents.
Each agent operates with its own reasoning loop. This enables independent decision-making and learning from outcomes. It’s different from traditional automation because agents are proactive rather than reactive. They adapt to changing conditions without you having to reprogram them.
The mechanism is called the TAO cycle: Think-Act-Observe. The agent analyses context and plans (Think), executes using available tools (Act), then evaluates outcomes and updates its understanding (Observe). This continuous loop enables agents to learn and improve without manual retraining.
The conversation has intensified because three enabling conditions have converged. LLM reasoning capability has matured, communication protocols are standardising, and orchestration frameworks have reached production readiness.
Use cases already in production? Customer service accounts for 26.5% of deployments, research and analysis represents 24.4%, and internal knowledge management is gaining traction.
The term “microservices moment” captures a specific pattern: the point where a distributed architecture becomes clearly superior to monolithic approaches for complex systems.
In software, the microservices moment arrived when containerisation (Docker), orchestration (Kubernetes), and API standardisation made it practical to decompose monoliths. For AI, an equivalent convergence is happening now. Advanced LLM reasoning provides the cognitive foundation. Protocol standards provide the communication layer. Frameworks provide the orchestration tooling.
Just as microservices didn’t replace all monoliths overnight, multi-agent will not replace all single-agent systems. The shift is towards using the right architecture for the right complexity level.
The “moment” is defined by market signals. Deloitte projects $35 billion by 2030, growing from $8.5 billion by 2026. Gartner predicts 40% of enterprise applications will incorporate agentic AI by 2026, up from less than 5% in 2025. And 93% of IT leaders report intentions to introduce autonomous agents within the next 2 years.
Both architectures evolved from the same pressure: complexity outgrows what a single unit can efficiently handle. Monolithic application to microservices mirrors monolithic LLM to single-agent to multi-agent. In both cases, the driver is specialisation, independent scaling, and fault isolation.
The analogy maps like this. Monolithic application maps to monolithic LLM. Service decomposition maps to agent specialisation. API contracts map to agent communication protocols. Service mesh maps to orchestration layer.
In microservices, services communicate through well-defined APIs with rigid contracts. In multi-agent systems, agents communicate through dynamic protocols that allow negotiation and adaptation. Instead of predefined API calls, agents exchange goals, capabilities, and results.
Microservices use centralised orchestration like service mesh or API gateway. Multi-agent systems offer three patterns: centralised (supervisor agent), decentralised (peer-to-peer negotiation), and hierarchical (nested delegation).
The key difference? Microservices are stateless and execute predefined logic. Agents maintain state, learn from outcomes, and can modify their behaviour through the TAO cycle.
The emerging trend is hybrid systems, where microservices handle stable transactional workloads while agents handle reasoning and orchestration. Think of microservices as a collection of tools and agentic AI as something that knows when and why to use each one.
Shared challenges? Both face complexity in debugging distributed interactions, require robust observability, and demand new operational skills from teams.
Three categories of enabling technology have matured simultaneously. This convergence mirrors the Docker-Kubernetes-REST moment for microservices. Each technology alone was insufficient, but together they made the pattern practical.
First, LLM capability maturity. Models can now reason, plan, use tools, and maintain context across extended interactions. This provides the cognitive foundation each agent needs to operate autonomously.
Second, protocol standardisation. Anthropic’s Model Context Protocol (MCP) standardises how agents access tools and contextual data. Google’s Agent2Agent (A2A) protocol governs peer coordination and delegation. Cisco’s AGNTCY provides agent coordination standards for enterprise deployments. The industry is converging toward 2-3 dominant standards.
Third, framework proliferation. LangGraph, CrewAI, and AutoGen have reached production-grade maturity. They provide abstractions that simplify defining agent roles, goals, and communication patterns.
The protocol standardisation race determines whether the ecosystem will be open and interoperable or locked into vendor-specific walled gardens. Excessive competition across protocols could risk “walled gardens”, where companies are locked into one protocol and agent ecosystem.
AWS Bedrock and IBM Watsonx Orchestrate are embedding multi-agent capabilities. This reduces the engineering effort required for organisations without dedicated AI teams.
The autonomous AI agent market is projected to reach $35 billion by 2030, growing from $8.5 billion by 2026. IDC projects overall AI spending growth of 31.9% annually through 2029, reaching $1.3 trillion, with agentic AI as a primary growth driver.
The shift is already underway. 57% of organisations have AI agents in production. Gartner predicts 40% of enterprise applications will incorporate agentic AI by 2026, and by 2028, 33% of enterprise software will include agentic AI, enabling 15% of day-to-day work decisions to be made autonomously.
Guardian agents, focused on risk management and compliance, are expected to capture 10-15% of the agentic AI market by 2030. This signals institutional maturity—governance as an architectural component rather than an afterthought.
Now for the reality check. Gartner estimates more than 40% of agentic AI projects could be cancelled by 2027, due to unanticipated cost, complexity, or unexpected risks. Market growth does not guarantee organisational success. Careful assessment and realistic expectations are essential. Understanding why multi-agent projects fail and how to avoid the same mistakes is critical before committing resources.
Multi-agent orchestration isn’t universally the right choice. Specific problem characteristics determine whether it adds value or adds unnecessary complexity.
Problems that benefit from multi-agent? Context overflow, where a single agent can’t hold all relevant information. Specialisation conflicts, where one agent can’t be expert in all required domains. Parallel processing needs, where tasks can be decomposed and executed concurrently. And security boundary requirements, where different agents operate at different trust levels.
Problems better served by single-agent? Well-defined tasks with clear inputs and outputs. Low complexity requiring no domain specialisation. Cost-sensitive deployments where orchestration overhead is unjustified. And environments where simplicity of debugging outweighs coordination benefits.
Use Microsoft’s Azure Cloud Adoption Framework to evaluate security boundaries, team structure, growth trajectory, role complexity, time-to-market needs, and cost priorities. Build multiple agents when regulations mandate strict data isolation, when distinct teams manage separate knowledge areas, or when your solution roadmap spans more than three to five distinct functions.
Don’t assume role separation requires multiple agents. Often a single agent using persona switching and conditional prompting can satisfy role-based behaviour without added orchestration.
Organisational readiness matters. Does your team have distributed systems experience? Is there existing infrastructure for monitoring and observability? Is leadership prepared for the shift from deterministic processes to probabilistic outcomes?
A practical decision tree. If your use case involves fewer than three distinct domain specialisations, a single agent is likely sufficient. If it requires parallel processing across security boundaries with multiple knowledge domains, multi-agent becomes compelling. For a detailed framework on deciding between single-agent and multi-agent architectures, including specific problem categories and anti-patterns, comprehensive guidance is available.
Start with honest assessment of current maturity rather than aspiration. A strong single-agent implementation is better than a poorly governed multi-agent system.
ROI from multi-agent systems is real but not instant. 88% of US executives report seeing ROI from AI investments, yet Gartner’s 40% cancellation rate indicates that poor planning accounts for most failures. Organisations are seeing 5x-10x returns in successful implementations.
Typical adoption follows a crawl-walk-run pattern. Start with a single well-scoped agent, validate ROI, then progressively add agents as competence and infrastructure mature. Expect 6-12 months to achieve meaningful single-agent ROI before expanding to multi-agent.
ROI calculation should combine tangible savings (cost reduction, productivity gains, revenue growth) with intangible value (improved agility, faster time-to-market, employee satisfaction). Use the formula: ROI = (Net Benefit / Total Investment) x 100%, where costs include infrastructure, frameworks, team training, governance tooling, and ongoing observability.
Measurable benefits? Cost reduction of $1-$4 saved per $1 spent, with 80% lower Tier-1 support costs documented. Productivity gains of 20-30% more output for same spend. Revenue growth of 10-30% increase in sales and conversions.
The hybrid systems approach is recommended. Microservices handle stable transactional workloads while agents progressively take over reasoning and orchestration. This approach forms a core principle of effective multi-agent AI orchestration strategies.
Human-in-the-loop patterns are necessary during early adoption. The autonomy spectrum moves from continuous human oversight to periodic review to monitored autonomy as trust matures.
Common failure patterns? Over-scoping initial implementations, underinvesting in observability, neglecting governance frameworks, and treating multi-agent as a technology project rather than an organisational change initiative.
Before evaluating tools or frameworks, ask “What specific problem would multi-agent solve that our current approach cannot?” If the answer is vague, the timing is wrong.
Assess architectural fit. Does your current workload involve multiple distinct domains that require specialised knowledge? Do you need parallel processing across trust boundaries? Is context overflow limiting your single-agent effectiveness?
Evaluate team readiness. Does your engineering team have experience with distributed systems, event-driven architectures, or microservices patterns? If not, invest in foundational skills before multi-agent adoption.
Consider governance requirements. How will you monitor agent decisions? What compliance requirements apply? Where do human approval gates need to exist in your workflows?
Map the ecosystem. Which orchestration frameworks (LangGraph, CrewAI, AutoGen) align with your existing technology stack? Which communication protocols (MCP, A2A) does your tooling ecosystem support?
Challenge vendor narratives. Every platform vendor is positioning multi-agent capabilities. Distinguish between genuine orchestration and rebranded workflow automation.
Plan the exit. If multi-agent doesn’t deliver expected outcomes, what’s your fallback? A well-designed single-agent system should remain viable as a graceful degradation path.
Identify who in your C-suite will own your organisation’s AI agent vision and strategy with aligned incentives and accountability. Stress-test orchestrations rigorously before scaling. Simulate with real complexities—incomplete data, conflicting goals, or adversarial scenarios.
For organisations ready to proceed, getting started with multi-agent implementation requires a structured three-phase approach with pilot project selection and realistic ROI expectations.
Traditional workflow automation follows pre-defined, deterministic sequences where each step is explicitly programmed. Multi-agent AI uses autonomous agents that can reason, adapt, and make independent decisions through the TAO cycle (Think-Act-Observe). Agents can negotiate with each other, handle unexpected inputs, and learn from outcomes. This makes them suited to complex, dynamic tasks that workflow automation can’t handle.
The analogy is imprecise in two key areas. First, microservices are stateless and execute pre-defined logic, while agents maintain state, learn from outcomes, and modify their behaviour over time. Second, microservices communicate through rigid API contracts, while agents can negotiate dynamically through evolving protocols. The analogy is strongest for understanding decomposition, specialisation, and independent scaling.
The TAO cycle (Think-Act-Observe) is the reasoning loop that makes agents autonomous. In the Think phase, the agent analyses its current context and plans actions. In the Act phase, it executes those actions using available tools. In the Observe phase, it evaluates outcomes and updates its understanding. This continuous loop enables agents to learn and improve without manual retraining. It’s what differentiates them from static automation.
Most small companies are better served by well-implemented single-agent systems. Multi-agent orchestration adds coordination overhead, observability requirements, and governance complexity that typically only pays off when workloads involve multiple distinct knowledge domains, security boundaries, or parallel processing needs. Start with a single agent, validate ROI, and only expand when specific limitations of the single-agent approach become evident.
Three major protocols are emerging. Anthropic’s Model Context Protocol (MCP) for standardising how agents access tools and contextual data. Google’s Agent2Agent (A2A) for inter-agent communication. And Cisco’s AGNTCY for agent coordination standards. The industry is converging toward 2-3 dominant standards, similar to how REST and gRPC became dominant in the microservices era.
Use the formula: ROI = (Net Benefit / Total Investment) x 100%, where Net Benefit combines tangible savings (cost reduction, productivity gains, revenue growth) with intangible value (improved agility, time-to-market, satisfaction). Include costs for infrastructure, frameworks, team training, governance tooling, and ongoing observability. Most organisations should expect 6-12 months to achieve meaningful single-agent ROI before expanding to multi-agent.
Guardian agents are specialised agents focused on risk management, compliance validation, and governing the behaviour of other agents. They monitor agent decisions, enforce policy constraints, and prevent unsafe actions. Gartner expects guardian agents to capture 10-15% of the agentic AI market by 2030. This indicates that governance is becoming an architectural component rather than an afterthought.
Gartner estimates a 40% cancellation rate for agentic AI projects. The main reasons? Over-scoping, unrealistic expectations, insufficient governance, and treating the initiative as a technology project rather than an organisational change effort. Success rates improve substantially when organisations adopt a phased approach, starting with well-scoped single-agent implementations before expanding to multi-agent coordination.
Running multiple chatbots means operating several independent, disconnected systems that don’t communicate or coordinate. Multi-agent orchestration means those agents share context, delegate tasks to each other, negotiate approaches, and work toward shared objectives through defined patterns (centralised, decentralised, or hierarchical). The orchestration layer is what transforms independent agents into a coordinated system.
Teams need distributed systems expertise (similar to microservices experience), understanding of event-driven architectures, familiarity with at least one orchestration framework (LangGraph, CrewAI, or AutoGen), comfort with probabilistic rather than deterministic outcomes, and skills in observability and monitoring for non-linear agent interactions. If your team has microservices experience, the transition is more natural.
Market evidence supports a genuine shift. 57% of organisations have agents in production, the market is projected to reach $35 billion by 2030, and major technology platforms are embedding native multi-agent capabilities. However, not every organisation needs multi-agent architecture, and the 40% project cancellation rate indicates that hype-driven adoption without clear use-case fit is a real risk.
The agent layer sits above microservices infrastructure. It uses existing services for stable transactional workloads while adding autonomous decision-making and dynamic coordination. This hybrid approach means organisations don’t need to replace their microservices. Agents consume and orchestrate existing services while handling the reasoning, planning, and adaptive coordination that static service orchestration can’t provide.
Software Supply Chain Security After SolarWinds and XZ UtilsIn December 2020, approximately 18,000 organisations received backdoored software through routine SolarWinds Orion updates. The attackers were Russian intelligence. Their malware lived inside digitally signed, legitimate-looking updates for over 14 months before anyone noticed. Four years later, a Microsoft engineer happened to notice that SSH connections were taking 500 milliseconds longer than expected. That anomaly led to the discovery of a CVSS 10.0 backdoor planted in the XZ Utils compression library through a multi-year social engineering campaign targeting a burned-out volunteer maintainer.
These aren’t edge cases. Third-party breaches now account for 30% of all data breaches, doubling year-over-year. Over 75% of organisations experienced a software supply chain attack within the past year. Malicious open source packages have grown by 156% annually, with 1,300% growth between 2020 and 2023. Global costs from supply chain compromise are projected to hit $60 billion in 2025, escalating to $138 billion by 2031.
If you’re responsible for a software product and the team that builds it, supply chain security is no longer something you can delegate to “the security people” and forget about. It requires strategic decisions about tooling, process changes, and where you spend money. This guide covers the threat landscape, the frameworks that emerged in response, and the practical steps that actually reduce risk.
It also serves as your navigation hub to nine detailed articles:
Let’s start with the fundamentals.
Software supply chain security protects the development, build, and distribution processes from compromise. Unlike traditional attacks targeting running applications, supply chain attacks inject malicious code during development or distribution, affecting all downstream users. The 2020 SolarWinds breach (18,000 organisations compromised via malicious build system updates) and 2024 XZ Utils backdoor (multi-year social engineering of a maintainer) demonstrate how adversaries shifted from endpoint attacks to upstream compromise, scaling impact exponentially.
The economic truth is stark: compromising a single widely-used component reaches thousands of targets at once. Your average SaaS application pulls in around 203 direct dependencies and over 1,200 transitive ones. Each is a potential entry point. More than 70% of organisations experienced at least one material third-party cybersecurity incident in the past year. Average breach costs run to $4.44 million globally, with US breaches reaching $10.22 million.
Three defining incidents reshaped the landscape. The SolarWinds SUNBURST attack showed nation-states can compromise build systems to distribute malware through trusted update channels. The XZ Utils backdoor demonstrated that social engineering of volunteer maintainers is a viable multi-year attack strategy. And the tj-actions GitHub Actions compromise proved that CI/CD pipelines themselves are high-value targets where mutable tags can be weaponised to steal secrets from thousands of repositories.
These incidents catalysed the adoption of frameworks like SLSA for build integrity and SBOM for component transparency, while exposing critical vulnerabilities in maintainer sustainability and dependency management practices.
Supply chain attacks exploit trust relationships in software development. Attack vectors include: (1) compromising build systems to inject malware into legitimate updates (SolarWinds model), (2) social engineering maintainers to gain commit access (XZ Utils model), (3) dependency confusion attacks uploading malicious packages with trusted names, and (4) compromising CI/CD pipelines to steal credentials or modify artefacts. Each model bypasses traditional security controls by operating within trusted processes.
Understanding these four models helps you figure out where your defences need strengthening.
Build system compromise targets the infrastructure that compiles and packages software. Attackers gain access through credential theft or insider access, inject malicious code during compilation, and the resulting software is signed with legitimate certificates and distributed through official channels.
Social engineering takeover targets the people who maintain software. Attackers build trust over months or years through legitimate contributions, exploit maintainer burnout, and eventually gain commit access to introduce backdoors disguised as benign refactoring.
CI/CD pipeline attacks target the automation that builds and deploys software. Platforms like GitHub Actions hold production credentials. Mutable tags allow attackers to substitute malicious code after workflows already reference those tags, and a compromised action can dump environment secrets to logs or exfiltrate them externally.
Dependency confusion targets the package resolution process. Attackers upload a malicious package to a public registry using a name matching a private internal package. Build tools that prioritise public registries download the malicious version instead.
The common thread is that all four models exploit trust. Signed artefacts, legitimate maintainers, approved actions, public registries — these are things your systems are configured to accept. When malicious code arrives through these authorised channels, it bypasses the security controls you already have in place.
Defending against these attack vectors requires a layered approach. Hardening your CI/CD pipelines addresses build system and workflow compromise. Selecting the right security tools provides the detection and analysis capabilities needed to spot malicious packages before they enter your codebase.
For detailed technical breakdowns of how each model plays out in practice, see the next section and our dedicated analyses of SolarWinds build infiltration, the XZ Utils social engineering campaign, and responding to the tj-actions compromise.
SolarWinds (2020): Russian APT29 compromised SolarWinds’ build system, injecting SUNBURST malware into Orion platform updates signed with legitimate certificates. 18,000+ organisations received backdoored software, with attackers selectively activating malware in ~100 high-value targets including US Treasury and Commerce departments. XZ Utils (2024): Multi-year social engineering campaign gained maintainer access to xz compression library, inserting CVSS 10.0 backdoor targeting OpenSSH authentication. Discovered accidentally via 500ms SSH delay, narrowly preventing Linux distribution compromise.
These two incidents illustrate the two ends of the supply chain attack spectrum: infrastructure compromise and human exploitation. Understanding both clarifies why no single defensive measure is sufficient.
SolarWinds SUNBURST (December 2020) was a Russian intelligence operation. APT29 compromised SolarWinds’ build system, injecting the SUNBURST backdoor into Orion platform updates signed with legitimate certificates. Around 18,000 organisations received compromised updates, though attackers selectively activated the backdoor in roughly 100 high-value targets including the US Treasury, Commerce Department, and Department of Homeland Security. The attackers managed their intrusion through multiple US-based servers and mimicked legitimate network traffic, evading detection for over 14 months. FireEye discovered the campaign in December 2020 when attackers stole their red team tools.
The regulatory response was immediate and structural. Executive Order 14028 mandated Software Bills of Materials (SBOM) for federal software procurement. Google proposed the SLSA framework shortly after, providing a structured approach to build integrity and provenance tracking.
XZ Utils Backdoor CVE-2024-3094 (March 2024) took a completely different approach. A pseudonymous actor called “Jia Tan” created an identity in 2021, earned commit access by 2022 through legitimate contributions, and inserted a CVSS 10.0 backdoor in February 2024. The backdoor targeted OpenSSH authentication through obfuscated test files, affecting xz-utils versions 5.6.0 and 5.6.1 that had already landed in Fedora 41 and Debian testing.
The discovery was accidental. Andres Freund, a Microsoft engineer, noticed a 500-millisecond SSH delay during performance testing and investigated. Computer scientist Alex Stamos called it potentially “the most widespread and effective backdoor ever planted in any software product.” The incident ignited a discussion about whether critical cyberinfrastructure should depend on unpaid volunteers.
Both attacks demonstrated nation-state sophistication and multi-year planning. Where SolarWinds targeted build infrastructure, XZ Utils targeted maintainer psychology. Together, they catalysed the framework adoption and regulatory responses that now define the supply chain security landscape.
The SolarWinds attack drove immediate adoption of build integrity frameworks and SBOM requirements. The XZ Utils incident exposed how maintainer burnout creates security vulnerabilities and highlighted gaps in dependency management practices.
For detailed analyses, see the SolarWinds SUNBURST case study and the XZ Utils backdoor deep dive.
SLSA (Supply-chain Levels for Software Artefacts, pronounced “salsa”) is a security framework providing four maturity levels for build integrity, from basic provenance (Level 1) to tamper-resistant builds (Level 3-4). SBOM (Software Bill of Materials) inventories all software components, versions, and dependencies. SLSA ensures builds aren’t tampered with; SBOM ensures you know what’s in your software. Together, they provide build integrity and component transparency, enabling rapid vulnerability response and meeting regulatory requirements (Executive Order 14028).
Two complementary frameworks emerged from these incidents. SLSA handles build integrity. SBOM handles component transparency. You need both, but you don’t need to implement them simultaneously.
SLSA (Supply-chain Levels for Software Artefacts, pronounced “salsa”) is a security framework developed by Google and maintained by the OpenSSF. It defines four maturity levels for build integrity, with Level 0 as the implicit baseline:
The practical takeaway: SLSA Level 2 is achievable for most teams in two to four weeks using hosted build services. It would have made the SolarWinds-style build tampering detectable. Levels 3 and 4 require substantial infrastructure investment and are typically justified only for high-security environments or specific compliance requirements.
SBOM (Software Bill of Materials) is a comprehensive inventory of all software components, dependencies, and metadata within an application. Think of it as a nutritional label for software. Executive Order 14028 requires SBOM for federal software procurement, and CISA has published 2025 minimum elements: author, supplier, component name, version, dependencies, unique identifier, and timestamp.
Two format standards dominate. CycloneDX is the OWASP standard, security-focused and extensible for vulnerability enrichment. It’s the recommended choice for most teams. SPDX is an ISO standard with comprehensive licensing metadata, preferred in regulated industries and some government contracts.
The operational value is immediate. Organisations with SBOMs pinpointed Log4j-affected components within hours of disclosure. Those without faced weeks of manual inventorying.
Here’s how the two frameworks relate: SLSA answers “Was this artefact tampered with during build?” SBOM answers “What components are in this artefact and do they have known vulnerabilities?” Neither is sufficient alone. Together with CI/CD security hardening and the right security scanning tools, they form a comprehensive defensive posture.
Start with SBOM. It’s easier to implement, delivers immediate regulatory and operational value, and provides the foundation for everything else. Then progress to SLSA Level 2. For detailed implementation guidance, see the SLSA build integrity guide and the SBOM implementation roadmap.
Open source maintainer burnout creates security vulnerabilities. Overwhelmed volunteer maintainers are susceptible to social engineering (XZ Utils), abandon projects creating unmaintained dependencies, and lack resources for timely security patching. Data shows foundation-supported projects (Apache, CNCF, Eclipse) remediate vulnerabilities 264 days faster than independent projects. Paid maintainer programs (Tidelift, Open Source Pledge) deliver 3x fewer unfixed vulnerabilities and 55% higher security practice adoption. Maintainer sustainability is infrastructure security investment.
The XZ Utils attack worked because a volunteer maintainer was overwhelmed, and that’s not an isolated case. The Kubernetes Ingress NGINX controller was reduced to a single part-time maintainer. The External Secrets Operator nearly collapsed until CNCF intervened. Industry-wide, 67% of critical open source infrastructure is maintained by volunteers with no organisational backing.
Governance and funding models directly affect security outcomes. Foundation-supported projects under Apache, Eclipse, and CNCF show 264 days faster median remediation time and 73% adoption of security best practices compared to 28% for independent projects. Paid maintainer programs like Tidelift deliver 45% faster security issue resolution and three times fewer unfixed vulnerabilities over 12 months.
Burnout creates a specific attack surface. Overwhelmed maintainers are susceptible to social engineering. They skip code reviews. When they quit without succession planning, dependencies become unmaintained with unfixed vulnerabilities accumulating silently.
What does this mean practically? Prefer projects with foundation backing or paid maintainer models. Use OpenSSF Scorecard to assess project health before adoption. Watch for red flags: single maintainer, no commits in six months or more, unanswered security issues. And consider budgeting for maintainer sponsorship — the Open Source Pledge recommends $2,000 per developer per year. Sponsoring the maintainers of libraries your product depends on is an infrastructure investment that directly reduces your attack surface.
The XZ Utils backdoor demonstrated how catastrophically maintainer burnout can be exploited. Understanding how foundation support reduces security risk helps you make better dependency selection decisions and prioritise maintainer sustainability in your security strategy.
Active dependency management reduces risk 7x compared to passive approaches. The persistent risk framework explains why 95% of vulnerable downloads had fixes available — organisations fail to update, not due to patch unavailability. Implement automated updates (Dependabot, Renovate) with appropriate pinning strategies: applications should pin exact versions with automated updates; libraries should specify minimum compatible versions. Measure dependency age using libyears metric; target <2 years for critical dependencies.
One statistic defines the dependency management problem: 95% of vulnerable downloads had fixes already available. Organisations simply do not apply the patches they have.
Sonatype’s persistent risk framework breaks this down into two components. Unfixed risk covers vulnerabilities without available patches, accounting for roughly 5% of vulnerable downloads. Corrosive risk covers vulnerabilities where fixes exist but organisations haven’t applied them, accounting for the other 95%. The Log4Shell vulnerability illustrates this: three years after CVE-2021-44228 was published, 13% of Java applications remained vulnerable despite patches being available within days of disclosure.
Active dependency management reduces vulnerability exposure by seven times compared to passive approaches. Passive means manual updates when incidents occur. Active means automated scanning, continuous updates, and policy-driven acceptance criteria using tools like Dependabot or Renovate.
Your pinning strategy matters. Applications deployed to production should pin exact versions with lock files, using automated updates with test suites to control timing. Libraries consumed by other code should specify minimum compatible versions with upper bounds. Never use wildcard ranges.
The libyears metric tracks dependency health by measuring how many years behind the current release each dependency sits. Target less than two libyears for critical dependencies and less than five for non-critical ones. And remember the transitive dependency challenge: your average application has 203 direct dependencies but over 1,200 transitive ones. A vulnerability buried three levels deep still affects your application, and you need an SBOM to even see it.
When evaluating dependencies, also consider maintainer sustainability indicators — foundation-backed projects remediate vulnerabilities 264 days faster than independent projects. The combination of active dependency management and appropriate security tooling reduces your exposure significantly.
For the full persistent risk framework and tool comparison, see understanding persistent risk in dependency management and the supply chain security tool selection framework.
Immediate response: (1) Identify affected repositories and workflow runs via audit logs, (2) rotate all secrets accessible to compromised workflows (GitHub secrets, cloud credentials, API keys), (3) switch from mutable tags (v1) to commit SHA pinning (uses: actions/checkout@a81bbbf8298c0fa03ea29cdc473d45769f953675) for all third-party actions, (4) audit workflow logs for evidence of secret exfiltration, (5) implement OIDC for future credential access eliminating long-lived secrets.
The tj-actions incident in March 2025 demonstrated that CI/CD compromise is not theoretical. If you used tj-actions/changed-files at any version, your secrets may have been exposed through runtime memory dumping and log-based exfiltration. The response pattern applies to any CI/CD compromise.
Day one: contain and rotate. Identify affected repositories through audit logs. Rotate all secrets accessible to compromised workflows — GitHub secrets, cloud credentials, API keys, deploy tokens. Switch from mutable tags to commit SHA pinning for all third-party actions.
Week one: harden. Audit all third-party actions across your organisation. Implement branch protection rules requiring pull request reviews for workflow changes. Enable tag protection. Deploy runtime monitoring with StepSecurity Harden-Runner.
Weeks two through four: prevent recurrence. Migrate from long-lived secrets to OIDC for cloud access. Create an approved action allowlist. Document an incident response playbook for future CI/CD compromises.
The highest-return preventive measure costs nothing: replacing mutable tag references like actions/checkout@v3 with full commit SHA references like actions/checkout@8e5e7e5ab.... This single change eliminates the entire class of tag-based attacks. Like the SolarWinds attack targeted build systems, CI/CD pipelines are high-value targets that require comprehensive hardening.
For the complete incident response checklist, see responding to the tj-actions compromise. For comprehensive preventive hardening, see the GitHub Actions hardening guide.
Prioritise based on company size. 50-100 employees: Free tier baseline (GitHub Dependabot, OWASP Dependency-Track, OpenSSF Scorecard). 100-300 employees: Add commercial SCA (Snyk, Socket Security) for developer-friendly scanning and automated fix PRs ($50-100/developer/year). 300-500+ employees: Consider platform consolidation (Sonatype Nexus, JFrog Xray) integrating artefact management with security scanning (enterprise pricing). All companies: Implement SBOM generation (free via Syft/cdxgen) and commit SHA pinning in CI/CD (free, highest ROI).
Tool selection anxiety is real. There are dozens of options across free, commercial, and enterprise tiers. Here’s how to cut through it based on your organisation’s size.
All teams (free tier baseline, 1-2 weeks setup): GitHub Dependabot for automated dependency updates, OWASP Dependency-Track for SBOM consumption, OpenSSF Scorecard for dependency health assessment, and Syft or cdxgen for SBOM generation. Costs nothing. Limitation: manual triage and basic remediation guidance.
100 to 300 employees ($50-150 per developer per year): When manual triage causes productivity loss or compliance requires audit trails, upgrade to Snyk (developer-friendly UX, automated fix PRs) or Socket Security (deep package behaviour analysis, malware detection beyond known CVEs).
300 or more employees (~$100-200 per developer per year): Sonatype Nexus Lifecycle or JFrog Xray for organisations needing central artefact governance with integrated security scanning and compliance reporting.
The decision framework: Start free. Validate workflows. Upgrade when manual triage costs more than tooling. And don’t neglect the free wins — commit SHA pinning, OIDC migration, and branch protection rules deliver immediate risk reduction at zero cost. Combined with SLSA Level 2 implementation, you can achieve substantial security improvements within your first month.
For the comprehensive comparison including implementation effort and total cost of ownership, see the tool selection framework.
If you’re starting from scratch, begin with the incident case studies to understand the threat landscape. Then move to frameworks and standards for the defensive response. Finish with the implementation guides for CI/CD hardening, dependency management, and tool selection.
Budget $50-150 per developer per year for commercial tooling once you outgrow the free tier, plus $2,000 per developer per year for maintainer sponsorship through the Open Source Pledge. Start with free tools (Dependabot, OWASP Dependency-Track, Syft) to validate workflows first. The highest ROI comes from free controls: commit SHA pinning, OIDC migration, and branch protection rules. See the tool selection framework for cost breakdowns by company size.
CycloneDX for most teams: OWASP standard, security-focused, excellent tooling support through Syft, cdxgen, and OWASP Dependency-Track. Choose SPDX if you’re in a regulated industry or have government contracts requiring the ISO standard. Both meet CISA 2025 minimum elements. The real decision factor is downstream tooling compatibility — if your consumption platform (Dependency-Track, Snyk, etc.) prefers one format, let that guide your choice. See the SBOM implementation roadmap for detailed selection criteria.
Request their SBOM and SLSA attestations for all production artefacts. Review their CI/CD pipeline configuration for commit SHA pinning and OIDC usage. Check their OpenSSF Scorecard results for critical dependencies. Ask about their incident response playbook for supply chain compromises and whether they’ve executed it. A target without answers to these questions carries hidden technical debt that will become your problem post-acquisition. See the tool selection framework for what a mature supply chain security setup looks like.
SBOM is data: an inventory of components in a machine-readable format. SCA (Software Composition Analysis) is analysis: continuous scanning of that SBOM data against vulnerability databases to identify risks. SBOM enables SCA. SCA consumes SBOM. The workflow: generate SBOM during build, import into an SCA tool (Dependency-Track, Snyk), monitor for new CVEs, prioritise remediation. See the SBOM implementation guide and tool selection framework.
SOC 2 Trust Services Criteria and ISO 27001 Annex A both include controls for supplier relationships and software development security, but neither specifically mandates SLSA or SBOM. In practice, generating SBOMs and achieving SLSA Level 2 satisfies multiple audit requirements around change management, asset inventory, and vendor risk. If you’re pursuing either certification, building supply chain security into your compliance programme from the start avoids retrofitting controls later. See the SBOM implementation roadmap for how SBOM maps to compliance requirements.
Level 2: yes. GitHub Actions meets Level 2 requirements including provenance generation and signed attestations. Level 3: partially. It requires hardened build platforms with source/build isolation that GitHub-hosted runners don’t fully provide. Target Level 2 first and defer Level 3 until the baseline is mature. Common blockers for Level 3 include configuring hermetic builds, setting up isolated build environments, and implementing two-party review requirements — each of which typically requires dedicated infrastructure beyond what hosted CI/CD platforms offer. See the SLSA implementation guide for the level-by-level roadmap.
Supply Chain Security Tool Selection Framework Comparing Snyk Dependabot and Open Source AlternativesSince SolarWinds and XZ Utils turned supply chain attacks into headline news, the software supply chain security tools market has exploded. The problem isn’t finding tools—it’s cutting through the noise of too many overlapping options and working out which ones you actually need.
You’ve got dependency update tools like Dependabot and Renovate competing with vulnerability scanners like Snyk and Trivy, malicious package detectors like Socket and Phylum, and enterprise platforms like Sonatype and JFrog. Most comparison articles target either solo developers or enterprises with unlimited budgets. If you’re in that 50-500 employee SMB space, you’re pretty much left to work it out yourself.
This article gives you a structured decision framework that maps your organisational characteristics to actual tool recommendations across three tiers: free, commercial mid-market, and enterprise. Answer five questions and you’ll know which tier is right for you, with transparent cost and implementation effort estimates.
This guide is part of our comprehensive software supply chain security landscape, where we explore defensive frameworks, operational practices, and the systemic challenges facing modern development teams.
Software Composition Analysis is the umbrella term, but underneath you’ll find three distinct tool categories that address different supply chain risks. Individual SCA tools typically cover one or more of these layers, but rarely all three.
Layer 1 is dependency update automation. Tools like Dependabot and Renovate keep your dependencies current by automatically creating pull requests when new versions drop. They reduce the window of exposure but don’t scan for vulnerabilities directly.
Layer 2 is vulnerability scanning and analysis. Snyk, OWASP Dependency-Track, Trivy, and Grype identify known vulnerabilities (CVEs) sitting in your dependencies. Commercial tools add reachability analysis to cut down false positives by working out whether vulnerable code paths actually get executed in your app.
Layer 3 is malicious package detection. Socket Security and Phylum detect intentionally malicious code that’s been injected into packages—which is a fundamentally different threat from accidental vulnerabilities. Traditional SCA tools won’t catch a deliberately planted backdoor.
Users constantly conflate these categories. They expect Snyk to handle updates or Dependabot to catch malicious packages. Comprehensive coverage means combining tools from multiple layers.
Enterprise platforms like Sonatype Nexus and JFrog Artifactory/Xray bundle multiple layers with repository management, policy enforcement, and compliance reporting. They control what enters your development environment rather than just flagging problems after you’ve already downloaded them.
OpenSSF Scorecard sits alongside these categories as a project health assessment tool. It evaluates upstream dependency risk rather than scanning your code directly.
What matters: no single tool covers all three layers. Even commercial platforms have coverage gaps in malicious package detection. You’re building a stack, not buying a solution.
The free tier stack—Dependabot + OWASP Dependency-Track + OpenSSF Scorecard—provides meaningful baseline coverage at zero licensing cost. Implementation takes 1-2 weeks. For teams under 50 developers working primarily on GitHub, this delivers 70-80% of the practical security value you’d get from commercial alternatives.
Dependabot is GitHub’s native dependency update tool. Enable it in your GitHub repository settings and you’re done in 30 minutes. The limitations are real though. It’s GitHub-only, groups updates poorly, and creates individual PRs that fragment developer attention.
OWASP Dependency-Track is the heavyweight in the free tier. It’s an open source platform for continuous SBOM analysis that consumes CycloneDX Software Bill of Materials created during CI/CD. It provides surprisingly capable vulnerability tracking, integrating with the National Vulnerability Database, Sonatype OSS Index, GitHub Advisories, Snyk, and OSV.
The catch? You need to self-host it. Budget 1-2 days for setup, plus $50-200 per month for cloud hosting. You’ll also need to generate SBOMs in your build pipeline.
OpenSSF Scorecard assesses the health of your upstream open source dependencies. It’s an automated security evaluation tool that examines important security heuristics and assigns scores between 0-10. Run it as a single command against public repositories or integrate it as a GitHub Action. Setup takes 2-4 hours.
Combined, these three tools cover dependency updates (Dependabot), vulnerability tracking (Dependency-Track), and upstream risk assessment (Scorecard). What they don’t cover: malicious package detection, reachability analysis, policy enforcement gates, or compliance reporting. For context on how these tools fit into a broader vulnerability management strategy, see our guide on persistent risk in dependency management.
Engineering time is the hidden cost. Expect 10-20 hours for initial setup and 2-5 hours per week for ongoing maintenance and triage. For a 100-person organisation, that’s $15,000-30,000 per year in engineering time even with zero licensing fees.
The choice comes down to simplicity versus configurability. Dependabot is simpler to enable but less flexible. Renovate is more powerful but needs more setup.
Dependabot’s advantages are all about ease. Native GitHub integration means zero infrastructure. Click a button in GitHub settings and automated security updates start flowing. No configuration required, free for all repositories.
Dependabot’s limitations frustrate teams at scale. It’s GitHub-only, so if you’re using GitLab, Bitbucket, or Azure DevOps, you’re out of luck. Limited grouping means related updates come in separate PRs. Less flexible scheduling creates noise. According to GitHub’s own data, repositories with automated dependency updates experience 40% fewer security vulnerabilities—but that assumes you can keep up with the PR volume.
Renovate’s advantages are about control. Platform-agnostic means it works across GitHub, GitLab, Bitbucket, and Azure DevOps. Powerful grouping and scheduling rules reduce PR noise. Auto-merge for safe updates. Regex-based custom managers. Monorepo-aware. Extensive preset system that lets you inherit configurations from the community.
Renovate’s limitations are the flip side of that power. You need hosted infrastructure—either self-hosted or Mend.io hosted. More complex initial configuration. Steeper learning curve.
For teams using only GitHub with straightforward dependency needs, Dependabot is the pragmatic choice. For teams with multi-platform repositories, monorepos, or needing auto-merge policies, Renovate is worth the setup investment.
Both are dependency update tools, not vulnerability scanners. Neither replaces the need for SCA scanning. The migration path from Dependabot to Renovate is straightforward if your needs evolve.
The upgrade decision should be triggered by concrete signals rather than arbitrary growth milestones. Look for these four triggers.
Trigger 1 is false positive overload. When OWASP Dependency-Track generates too many alerts without reachability context, developers start ignoring all alerts. Snyk’s reachability analysis reduces noise by 60-80% by identifying whether vulnerable code paths are actually executed. If your team is spending more than 5 hours per week triaging false positives, that’s your signal.
Trigger 2 is compliance requirements. Regulated industries like FinTech and HealthTech need audit trails, policy enforcement gates, and automated compliance reporting. Free tools can’t provide that. If you’re facing SOC 2, ISO 27001, or similar compliance frameworks, free tools won’t get you there. Our SBOM implementation roadmap covers the compliance dimensions in detail.
Trigger 3 is malicious package threat. If your threat model includes targeted supply chain attacks—not just accidental vulnerabilities—Socket Security or Phylum provide behaviour-based detection that no free tool offers. They detect install scripts, network calls, and obfuscated code that indicate malicious intent.
Trigger 4 is developer productivity. When security tooling friction slows development velocity, Snyk’s IDE integrations and developer-first workflow reduce context switching. Developers fix issues in their editor rather than bouncing between tools. For broader context on integrating security scanning into CI/CD workflows, see our GitHub Actions hardening guide.
Snyk pricing runs approximately $50-100 per developer per year for the Team plan. Free tier available for up to 5 users with limited scans. For 100 developers, that’s $5,000-10,000 annually in licensing plus 40-80 hours of implementation labour.
Socket Security and Phylum specialise in the malicious package detection layer. They complement traditional SCA rather than replacing it. You’d typically run Socket alongside Snyk, not instead of it.
The typical upgrade point is 100-300 employees, or when engineering time spent maintaining free tools exceeds the cost of a commercial licence. That crossover usually happens around 75-100 developers.
Enterprise platforms bundle repository management, artefact lifecycle control, and policy enforcement into a unified platform—capabilities that go beyond what mid-market SCA tools like Snyk provide.
Sonatype Nexus Lifecycle provides repository proxy that blocks vulnerable downloads at source, policy enforcement across the SDLC, automated compliance reporting, and deep vulnerability intelligence. The repository firewall automatically detects and blocks risky or malicious components from entering your repository. Strongest in policy granularity and compliance automation.
JFrog Artifactory + Xray emphasises artefact lifecycle management with integrated security scanning. Xray is natively integrated with Artifactory, enabling analysis of software artefacts and their dependencies. It identifies security issues and licence violations at the dependency declaration stage, blocking insecure builds before they progress. Stronger in DevOps workflow integration and binary management.
Both function as repository firewalls, blocking malicious or vulnerable packages before they enter your development environment. That’s a proactive approach not available in Snyk or free tools.
When enterprise platforms make sense: organisations with 300+ developers, multiple technology stacks, regulatory compliance obligations, or the need for centralised artefact governance across many teams.
Cost considerations: Enterprise pricing is custom-negotiated, starting significantly higher than Snyk. Expect $200-500+ per developer per year plus infrastructure costs for self-hosted deployments. For a 100-developer organisation, you’re looking at $20,000-50,000+ annually before engineering time.
Most 50-300 employee SMBs don’t need enterprise platforms. The additional capability doesn’t justify the cost and implementation complexity (1-3 months deployment). If you’re wondering whether you need it, you probably don’t.
Total cost of ownership for SCA tools extends far beyond licence fees. You need to account for implementation labour, infrastructure, ongoing maintenance, false positive triage time, and opportunity costs.
Free tier TCO looks like this for a 100-person organisation: $0 licensing, 40-80 hours implementation labour, self-hosted infrastructure for Dependency-Track ($50-200 per month cloud hosting), 8-20 hours per month ongoing maintenance, higher false positive triage burden. Estimated total: $15,000-30,000 per year in engineering time.
Mid-market commercial TCO using Snyk at $50-100 per developer per year: $5,000-10,000 per year licensing for 100 developers, 40-80 hours implementation, minimal infrastructure (SaaS), 4-8 hours per month maintenance, lower false positive burden. Estimated total: $15,000-25,000 per year including engineering time.
Notice something interesting? The free tier and commercial tier cost roughly the same once you factor in engineering time. The crossover point where commercial tools become cheaper than “free” typically occurs around 75-100 developers.
Enterprise platform TCO: $20,000-50,000+ per year licensing for 100 developers, 200-500 hours implementation (1-3 months), significant infrastructure requirements, 10-20 hours per month maintenance, requires dedicated platform owner. Estimated total: $50,000-100,000+ per year.
Implementation effort comparison: Free tier takes 1-2 weeks part-time. Snyk takes 2-4 weeks including policy configuration. Enterprise platforms take 1-3 months with a dedicated team.
Hidden costs that surprise teams: training and onboarding, integration with existing CI/CD pipelines, handling vendor-specific data formats, and migration costs if you switch tools later. Switching from Dependabot to Renovate takes 1-2 weeks, migrating to Snyk takes 2-4 weeks, transitioning to Sonatype or JFrog takes 1-3 months.
Tool selection maps to organisational characteristics along two axes: team size (determines budget and complexity) and security maturity (determines readiness for advanced tooling).
Tier 1 is startups and early-stage teams (10-50 developers). Use Dependabot + OpenSSF Scorecard. Focus on keeping dependencies updated and assessing upstream project health. Total investment: 1-2 days setup, near-zero ongoing cost.
Tier 2 is growing SMBs (50-100 developers). Add OWASP Dependency-Track to the baseline. Now you have Dependabot (or Renovate if multi-platform) + Dependency-Track + Scorecard. This adds SBOM-based vulnerability tracking. Total investment: 1-2 weeks setup, $15,000-30,000 per year in engineering time.
Tier 3 is scaling SMBs (100-300 developers). Add Snyk for reachability analysis and developer workflows. Add Socket Security if supply chain attack threats are relevant to your threat model. Maintain Dependabot or Renovate for updates—commercial tools complement rather than replace them. Total investment: $20,000-40,000 per year including licences and engineering.
Tier 4 is large SMBs (300-500 developers). Evaluate Sonatype Nexus or JFrog Artifactory/Xray for centralised artefact governance, policy enforcement, and compliance automation. Maintain mid-market tools during transition. Total investment: $50,000-100,000+ per year.
Maturity signals override size-based recommendations. If you face regulatory compliance requirements, accelerate to commercial tools regardless of size. If you’ve had an active incident response involving supply chain compromise, add Socket or Phylum immediately. If you’re managing multiple technology stacks, prefer Renovate over Dependabot from day one.
A 100-person SaaS company should start with Dependabot + Dependency-Track, then add Snyk when revenue exceeds $10M or compliance demands increase.
The recommendation sequence prioritises highest ROI actions: automated updates first (reduces exposure window), then vulnerability visibility (identifies problems), then advanced detection (catches sophisticated threats), then enterprise governance (manages at scale).
A maturity roadmap prevents both premature investment in enterprise tooling and dangerous delay in addressing growing security gaps.
Phase 1 is foundation (months 1-3). Enable Dependabot or Renovate across all repositories. Run OpenSSF Scorecard against your dependencies. Establish baseline visibility. Success metric: 100% of repositories have automated dependency updates.
Phase 2 is visibility (months 3-6). Deploy OWASP Dependency-Track. Begin generating and consuming SBOMs. Create a dependency inventory. For detailed guidance on SBOM generation and consumption, see our SBOM implementation roadmap. Success metric: complete SBOM for all production applications.
Phase 3 is analysis (months 6-12). Evaluate and deploy Snyk or equivalent commercial SCA for reachability analysis and policy enforcement. Integrate scanning into CI/CD pipeline as a gate. Success metric: zero high-severity vulnerabilities deployed to production.
Phase 4 is advanced detection (months 12-18). Add Socket Security or Phylum for malicious package detection if your threat model warrants. Implement repository firewall if using proxy repositories. Success metric: proactive blocking of suspicious packages.
Phase 5 is governance (months 18-24+). Evaluate enterprise platforms like Sonatype or JFrog only if centralised artefact management is needed at scale. Success metric: unified policy enforcement across all teams.
Each phase has explicit upgrade triggers. Move to the next phase when specific thresholds are met, not on arbitrary timelines. If false positives exceed 5 hours per week, move from Phase 2 to Phase 3. If compliance requirements emerge, accelerate to Phase 3 regardless of timeline. If malicious package threats materialise, jump to Phase 4.
Most organisations don’t need to reach Phase 5. Most 50-300 employee companies achieve adequate security posture at Phase 3. You’re not climbing a ladder where the top is the goal—you’re finding the right level for your risk tolerance and resources. For a complete understanding of how these tools fit into broader supply chain security strategies, explore the full range of defensive frameworks and operational practices.
Review and reassess tool choices annually. The SCA landscape evolves rapidly and new tools or improved free tiers may shift the optimal selection.
SCA analyses third-party open source components in your applications for known vulnerabilities, licence issues, and malicious code. SAST analyses your own source code for bugs. SCA covers supply chain risk from dependencies while SAST covers flaws in code you wrote. Most organisations need both, but SCA is the priority for supply chain security because dependencies represent the larger attack surface.
Renovate is more configurable and supports more platforms, but “better” depends on context. For GitHub-only teams with simple dependency needs, Dependabot’s zero-configuration approach is genuinely easier. For teams with monorepos, multiple platforms, or needing auto-merge rules, Renovate’s flexibility provides measurable workflow improvements. The migration path from Dependabot to Renovate is straightforward if needs evolve.
Yes, for baseline coverage. Dependabot + OWASP Dependency-Track + OpenSSF Scorecard provides dependency updates, vulnerability tracking, and upstream risk assessment at zero licence cost. However, free tools lack reachability analysis (more false positives), malicious package detection, and compliance reporting. For teams under 50 developers without regulatory requirements, the free tier delivers 70-80% of practical security value. Understanding how active dependency management reduces persistent risk helps maximise the value of these free tools.
Snyk’s Team plan costs approximately $50-100 per developer per year, so $5,000-10,000 annually for 100 developers. Add 40-80 hours of implementation labour ($4,000-8,000 at typical engineering rates) and 4-8 hours monthly maintenance. Total first-year cost: approximately $12,000-22,000. This is often comparable to the engineering time cost of maintaining free tools at the same scale.
Snyk leads in false positive reduction due to its reachability analysis, which determines whether vulnerable code paths are actually executed in your application. This typically reduces actionable alerts by 60-80% compared to tools that flag all known CVEs in dependencies. OWASP Dependency-Track and Trivy report all known vulnerabilities without reachability context, resulting in higher alert volumes that require manual triage.
A repository firewall blocks malicious or vulnerable packages at download time, before they enter your development environment. Sonatype Nexus and JFrog Artifactory provide this capability through proxy repositories. Most SMBs under 300 developers don’t need dedicated repository firewalls—the cost and complexity outweigh the risk reduction for smaller teams. Focus on dependency updates and vulnerability scanning first.
Signals to watch for: developers spending more than 5 hours per week managing Dependabot PRs, needing dependency updates across non-GitHub platforms, requiring auto-merge rules for low-risk updates, managing monorepos with complex dependency relationships, or wanting grouped updates to reduce PR noise. If three or more of these apply, evaluate Renovate or a commercial alternative.
A vulnerability is an accidental coding flaw in a legitimate package that attackers can exploit (like a buffer overflow). A malicious package is intentionally designed to cause harm (like the XZ Utils backdoor). Traditional SCA tools detect known vulnerabilities but not malicious packages. Tools like Socket Security and Phylum use behaviour analysis to detect malicious intent, addressing a fundamentally different threat category.
You don’t need an existing SBOM to begin evaluating tools, but SBOM capability should influence your selection. If your organisation faces SBOM compliance requirements (federal contracts, regulated industries), prioritise tools that generate and consume SBOMs: OWASP Dependency-Track for free tier, Sonatype or JFrog for enterprise. SBOM generation is increasingly table-stakes across all tiers.
Migration timelines vary significantly. Switching from Dependabot to Renovate takes 1-2 weeks (configuration translation). Migrating from free tools to Snyk takes 2-4 weeks (policy setup, team training). Transitioning to enterprise platforms like Sonatype or JFrog takes 1-3 months (infrastructure, workflow changes). Factor migration costs into your initial tool selection to avoid vendor lock-in penalties.
Dependabot requires zero configuration and activates in minutes from GitHub repository settings. OpenSSF Scorecard runs as a single command against any public repository. These two tools provide immediate, actionable security insights with no security expertise required. For the next level, Snyk’s developer-first approach and IDE integration make it the most accessible commercial option.
Language and package manager support matters but is often overstated in marketing. Evaluate based on the specific languages your team actually uses, not the total count. A tool supporting 40+ languages provides no advantage if you only use three. More important factors: quality of vulnerability data for your specific ecosystem, false positive rates, and CI/CD integration depth with your pipeline.
SBOM Implementation Roadmap From CISA 2025 Compliance to Operational Vulnerability TrackingIs SBOM just another checkbox for compliance audits, or does it actually deliver operational security value? The honest answer: it depends entirely on how you implement it.
When SBOMs get generated and then filed away for auditors, they’re compliance theatre. But when they’re continuously monitored against live vulnerability feeds and mapped to your actual deployments, they become your fastest response mechanism for zero-day vulnerabilities. The difference between those two outcomes is your consumption workflow, not your generation tooling.
This guide is part of our comprehensive software supply chain security framework, where we explore defensive controls from build integrity to dependency management. Here, we focus on SBOM implementation: what makes a compliant SBOM, how to integrate generation into your build pipeline, and how to establish continuous vulnerability tracking workflows that deliver operational value beyond regulatory requirements.
The good news is that implementing SBOMs properly isn’t complicated. You’ll make three decisions—format selection, generation tool, and consumption platform—then integrate them into your build pipeline. The whole process takes 1-2 weeks for most teams.
An SBOM is a formal record of software components and their supply chain relationships. Think of it as an ingredients list for your application—every open-source library, third-party dependency, and their nested dependencies, documented in a machine-readable format.
The operational value comes from speed. When Log4Shell was disclosed in December 2021, organisations with SBOMs identified affected systems in hours. Those without spent weeks manually inventorying dependencies across their environments. That’s the difference between contained damage and widespread compromise.
Unlike traditional inventory lists, SBOMs track nested dependencies and provenance throughout the software delivery lifecycle. When a vulnerability is disclosed, you query your SBOM to identify every affected component, including transitive dependencies you didn’t directly include.
This matters because most vulnerabilities appear in dependencies you inherit, not libraries you explicitly chose. Your application might not use Log4j directly, but if one of your 200 dependencies does, you’re exposed. SBOMs make that relationship visible.
Executive Order 14028, issued in 2021, established new requirements to secure the federal government’s software supply chain. If you sell software to federal agencies, you provide SBOMs. That federal procurement mandate is now driving industry-wide adoption as enterprises follow government practices.
SBOMs function as software blueprints. When security incidents occur, an SBOM pinpoints the vulnerable component, which means your team can prioritise response and assess broader impact.
The operational applications extend beyond vulnerability response. SBOMs enable licence compliance automation, dependency hygiene tracking, and vendor risk assessment. You’re analysing third-party component supply chains, identifying outdated or unmaintained dependencies, and detecting GPL contamination before it reaches production.
CISA notes that SBOM data can be transformed into insights to drive risk management decisions. The key word is “transformed”—raw SBOM files sitting in artefact repositories don’t drive decisions. Consumed SBOMs continuously evaluated against vulnerability feeds do.
CISA published updated guidance in 2025 to reflect current SBOM needs and capabilities. The minimum elements define what data must appear for each component in your SBOM. Think of this as the compliance baseline—the floor, not the ceiling.
The CISA minimum elements now include:
SBOM Author: Who created the SBOM. This establishes accountability for the data quality.
Software Producer: The entity that built the software. This is who you contact when issues are discovered.
Component Name: The actual name of each software component. Naming consistency matters for CVE mapping.
Component Version: Specific version numbers enable precise CVE mapping. A vulnerability might affect version 2.3.1 but not 2.3.2.
Component Hash: New in 2025, cryptographic hashes provide edition-specific accuracy for compiled binaries and container layers.
Dependency Relationships: How components connect to each other. This reveals transitive risk—if component A depends on vulnerable component B, you need to update A even though A itself isn’t vulnerable.
Timestamp: When the SBOM was generated.
On top of those, CISA 2025 introduces Licence (for compliance tracking), Tool Name (transparency in generation), and Generation Context (understanding SBOM scope).
CISA’s minimum elements apply to all software regardless of type, but comprehensive SBOMs include additional data. Best practice implementations add:
Package URLs (purl) for precise component identification across ecosystems. These are the primary lookup keys for vulnerability databases, reducing ambiguity.
Licence information beyond basic compliance. Detailed licence fields help track copyleft obligations and incompatible licence combinations.
External references like CVE IDs, security advisories, and documentation URLs. These accelerate remediation by linking directly to fix information.
The regulatory baseline gets you compliant. The comprehensive approach gets you operational value.
Two dominant SBOM standards implement the NTIA’s minimum elements: CycloneDX from OWASP and SPDX from the Linux Foundation. Both capture the same core data with different emphases and tooling ecosystems.
The practical reality is that format selection depends on your development workflow, not format superiority. Both work. Both are widely supported. The question is which fits your existing toolchain better.
CycloneDX was developed by OWASP Foundation with primary strength in vulnerability identification and outdated dependency analysis. It supports JSON, XML, and Protocol Buffers formats.
The security-centric design includes native VEX (Vulnerability Exploitability eXchange) support. VEX allows you to document when a CVE exists in your SBOM but isn’t exploitable in your application. This prevents alert fatigue when vulnerability scanners flag components you don’t actually use.
CycloneDX is lighter-weight and faster to implement than SPDX for most use cases.
SPDX was developed by Linux Foundation with primary strength in licensing compliance. It includes detailed fields for complex licensing information and is an ISO/IEC 5962 standard.
For regulated industries, ISO standardisation matters. Defence contractors, financial services, and healthcare organisations often require ISO-compliant standards. SPDX delivers that compliance.
Here’s the practical breakdown:
Choose CycloneDX when:
Choose SPDX when:
Both formats capture essential component data. Conversion tools exist if you need to switch later.
For most organisations, CycloneDX’s security focus and simpler implementation make it the recommended choice. Start there unless you have a specific requirement for SPDX.
SBOM generation should happen during your build process, not post-release. Embedding SBOM creation into CI/CD pipelines ensures every build includes current component inventories, which reduces human error and removes developer friction.
The implementation pattern is straightforward: install a generation tool, configure the output format, integrate it into your build step, then publish the SBOM artefact alongside your release.
Different tools excel in different ecosystems:
Syft from Anchore excels in container environments with fast scanning across Python, Go, Java, JavaScript, PHP, and Rust. It defaults to SPDX format but supports CycloneDX. Its speed and container focus make it ideal for Kubernetes deployments.
cdxgen is OWASP’s endorsed comprehensive SBOM generator supporting 20+ programming languages with CycloneDX output. It offers comprehensive transitive dependency resolution. For multi-language enterprise applications, cdxgen is the recommended choice.
npm-sbom is the best choice for Node.js, offering native integration supporting both CycloneDX and SPDX formats. Zero configuration required, comprehensive transitive dependency analysis included.
The recommendation is to prioritise single-language tools for accuracy when possible, choosing cdxgen for multi-language enterprise applications. Remember: imperfect SBOMs provide significantly more value than no SBOMs. For a comprehensive comparison of SBOM generation and consumption tools, including commercial platforms like Snyk and Sonatype, see our tool selection guide.
Once generated, SBOMs need to be stored and distributed. Options include:
Attaching to release artefacts in GitHub Releases or GitLab Package Registry. This keeps SBOMs versioned with releases.
Publishing to OCI registries alongside container images. The SBOM can be embedded in containers for distribution with images.
Submitting to consuming systems like Dependency-Track. This enables the operational monitoring that makes SBOMs valuable beyond compliance.
Secure SBOMs with digital signatures and checksums, logging each version and tracking changes to create verifiable audit trails.
SBOM value is created when the SBOM is consumed, continuously correlated with vulnerability intelligence, and mapped to deployment endpoints.
Generating SBOMs then filing them away accomplishes nothing operational. A consumed SBOM functions as a cryptographically anchored, continuously refreshable source of truth for post-deployment security.
OWASP Dependency-Track is an open source SBOM analysis platform providing continuous monitoring, policy enforcement, and integration with vulnerability databases like NVD, GitHub Advisories, and OSV.
The workflow is: generate SBOM during build, upload to Dependency-Track, continuous vulnerability scanning against live feeds, alert configuration based on severity thresholds, remediation tracking with deadlines.
Traditional software composition analysis tools focus on pre-deployment scanning and cannot answer operational questions about deployed software. Dependency-Track answers those questions by continuously evaluating SBOM data against live vulnerability intelligence. For comparisons with commercial alternatives like Snyk and Sonatype, see our SBOM consumption platforms analysis.
Upload integration happens via API. After generating your SBOM in the build pipeline, upload it to Dependency-Track for continuous monitoring.
The platform automatically scans the SBOM on arrival, mapping components to vulnerability databases using Package URLs, component name plus version, and cryptographic hashes. PURL is the primary OSV.dev lookup key, reducing ambiguity and false positives.
The advantage of automated upload is continuous monitoring. When SBOM and OSV.dev results are mapped to live production systems, teams immediately see which endpoints, containers, and binaries are affected by new CVEs.
Alert configuration enables targeted notifications. Set severity thresholds like CVSS ≥7.0 for high-severity vulnerabilities. Configure policy violations for GPL licences or known-malicious components. Route notifications through email, Slack, or PagerDuty.
Remediation tracking includes vulnerability suppression with justification, version upgrade recommendations, and remediation deadline tracking. When a CVE appears in your dependencies, Dependency-Track flags it, suggests the fixed version, and tracks your remediation progress.
The key is continuous re-consumption. New CVEs appear daily requiring real-time lookups, automated OSV.dev reprocessing, and dynamic remediation workflows. Your SBOM consumption practices must be continuous, not a point-in-time event.
SBOM and SLSA serve complementary purposes. SBOM provides component transparency—what’s inside your software. SLSA provides build integrity—how it was built. You need both for comprehensive supply chain security, but resource-constrained teams need to sequence them.
SBOM answers “what components are in this application?” SLSA answers “was the build process compromised?” SBOM provides the canonical definition of software composition, while SLSA provenance documents the build environment, build steps, and artefact integrity.
The integration benefits are real. Build provenance and component transparency work together to create supply chain visibility. SLSA provenance can include SBOM references. Combined approaches provide both “what” and “how” transparency. Sigstore keyless signing applies to both SBOMs and SLSA provenance, creating a unified verification workflow.
Implement SBOM first. Executive Order 14028 mandates SBOMs for federal procurement, creating immediate compliance pressure. SLSA is industry best practice without regulatory mandate yet.
SBOM implementation takes 1-2 weeks and requires tool integration plus artefact generation. SLSA requires build platform changes and takes 2-4 weeks to achieve Level 2.
SBOM implementation provides immediate operational value through vulnerability tracking. It establishes the foundation for SLSA by documenting what you’re building before you document how you build it.
Sequence: SBOM first (1-2 weeks), establish consumption workflow with Dependency-Track (1 week), then SLSA Level 2 (2-4 weeks). The total timeline is 4-7 weeks for both frameworks.
The maturity path for SBOM implementation has three stages: basic compliance, operational tracking, and risk-based prioritisation. Most organisations start at compliance and stop. The operational value lives in the latter two stages.
Zero-day response becomes your fastest capability. When vulnerabilities are disclosed, organisations with consumed SBOMs identify affected components in minutes, not weeks. You query your SBOM database, identify affected systems, prioritise based on operational exposure.
Licence compliance automation prevents GPL contamination before deployment. Your consumption platform flags licensing violations based on policy rules, blocking builds that introduce incompatible licences.
Dependency hygiene tracking identifies outdated and unmaintained dependencies. You track dependency age through continuous component analysis, identify components without active maintenance, and prioritise updates based on abandonment risk. SBOMs become the foundation for tracking dependency vulnerabilities through your entire application portfolio.
Traditional audits generate SBOMs annually or quarterly, then file them for compliance. Continuous security regenerates SBOMs every build and continuously scans against NVD and OSV feeds.
The difference is response time. Point-in-time SBOMs tell you what was true when they were generated. Continuous monitoring tells you what’s true right now, updated as new CVEs are published.
Stage one is compliance checkbox: generate SBOM artefact, attach to release, satisfy auditors. You have SBOMs but don’t use them.
Stage two is operational tracking: continuous vulnerability monitoring, automated alerts, remediation tracking. You use SBOMs to respond to disclosed vulnerabilities faster.
Stage three is risk-based prioritisation: combine SBOM data with CVSS scores, EPSS exploitability predictions, and business context. You prioritise remediation based on operational exposure, not raw CVE counts.
Advanced capabilities at stage three include VEX statements for false positive suppression, SBOM diff analysis showing what changed between releases, and supply chain risk scoring per component.
The compliance theatre concern is valid if SBOMs are only generated for audits then ignored. Operational value requires consumption: upload to Dependency-Track, configure alerts, integrate with vulnerability management.
The ROI becomes visible during incident response when you can identify affected systems in hours rather than conducting manual dependency inventories. Federal mandate creates industry momentum, but operational benefits justify implementation regardless of compliance requirements.
Yes. SBOM generation tools analyse installed dependencies, not just first-party code. Tools like Syft scan container images, package manager lock files, and installed binaries.
The limitation is that SBOM quality depends on artefact metadata. Maven and npm packages include excellent dependency metadata, so generated SBOMs are comprehensive. Compiled binaries without metadata produce limited SBOMs.
Two approaches exist: single comprehensive SBOM covering all components, or per-service SBOMs for each deployable unit.
Per-service SBOMs are recommended because they enable granular vulnerability tracking and clearer ownership. When a vulnerability appears, you know exactly which service is affected.
The trade-off is more SBOMs to manage versus more precise vulnerability attribution. For microservices architectures, precision wins.
Both list specific component versions, but SBOMs include standardised formats (CycloneDX/SPDX) that are machine-readable across ecosystems.
Lock files like package-lock.json are ecosystem-specific. They enable build reproducibility but lack supplier metadata, licence data, and vulnerability correlation fields.
Use both: lock files for build reproducibility, SBOMs for vulnerability tracking and compliance. SBOM generation often uses lock files as input source.
Recommended: every build or release to ensure SBOMs reflect actual deployed components. Embedding SBOM creation into CI/CD pipelines ensures every build includes current component inventories.
Automation eliminates regeneration burden. Manual regeneration creates staleness risk. SBOM artefacts are typically under 1MB, so storage cost doesn’t constrain frequency.
No. SBOM role is transparency and tracking, not malware detection. SBOMs enable rapid response once backdoors are discovered, identifying whether you use affected components and which versions.
SBOMs do not detect zero-day backdoors before disclosure. Complementary tools are required: SLSA provenance verifies build integrity, OpenSSF Scorecard assesses maintainer health, runtime monitoring detects anomalous behaviour.
SBOM value is incident response speed, not prevention.
VEX (Vulnerability Exploitability eXchange) provides metadata indicating vulnerability applicability to specific products. Use case: your SBOM shows a vulnerable component, but the code path isn’t reachable in your application.
This prevents alert fatigue. Suppress false positives with justification. Your security team acknowledges the CVE but documents non-exploitability.
Implement VEX after establishing basic SBOM workflow. It addresses alert fatigue in mature programmes, not initial implementations.
Business case elements include regulatory compliance for federal procurement, customer requirements from enterprise buyers demanding SBOMs, operational efficiency through faster vulnerability response, and risk reduction.
Implementation cost is low: 1-2 weeks engineering time with open source tooling available.
Competitive advantage: SBOM provision differentiates in enterprise sales and demonstrates security maturity. Start small: pilot with single service, demonstrate value, expand organisation-wide.
GitHub Dependency Graph provides SBOM-like functionality for repositories hosted on GitHub. Advantages: automatic, no configuration required, integrates with Dependabot alerts.
Limitations: GitHub-only so not portable, limited format export, no support for custom registries, less comprehensive than dedicated tools.
Recommendation: GitHub Dependency Graph is sufficient for GitHub-native workflows. Generate explicit SBOMs for compliance requirements, vendor distribution, or cross-platform analysis.
Container scanning tools like Trivy and Grype generate SBOMs as part of scanning process. The workflow integration is: scan container image, extract SBOM, upload to Dependency-Track, enable continuous vulnerability tracking.
Cryptographic hashes in SBOMs provide edition-specific accuracy for container layers. SBOM persistence matters because the SBOM outlives the container image, enabling historical vulnerability analysis.
Recommendation: integrate container scanning with SBOM extraction. Don’t rely on scanning alone.
Validation tools include NTIA SBOM Checker CLI tool, CycloneDX validation API, and SPDX validation tools. Manual verification checks for author, supplier, component name, version, unique identifier, dependency relationships, and timestamp fields.
Automated validation in CI/CD adds SBOM validation step after generation, failing builds if minimum elements are missing.
Common issues: missing supplier information where tools default to “unknown”, incomplete dependency graphs with transitive dependencies omitted, missing timestamps.
Validate during implementation phase, then automate validation to prevent regression.
Information disclosure concern: SBOMs reveal internal dependencies, potentially exposing proprietary libraries or security vulnerabilities.
Mitigation strategies include redacting proprietary components, providing summarised SBOMs with major dependencies only, offering SBOMs under NDA, and using VEX to indicate patched vulnerabilities.
Industry practice: SBOM provision is increasingly standard in enterprise procurement. Refusing creates competitive disadvantage.
Recommendation: implement internal SBOM workflow first, develop external distribution policy once comfortable with process.
You’ve got three decisions to make: format (CycloneDX for most, SPDX when ISO required), generation tool (Syft for containers, cdxgen for multi-language, language-specific for single ecosystems), and consumption platform (Dependency-Track for open source, commercial if budget allows).
Implementation timeline is 1-2 weeks. Week one: select tools, integrate generation into build pipeline, validate CISA minimum elements. Week two: deploy Dependency-Track, configure upload automation, establish alert policies.
The operational value appears in week three when the first vulnerability is disclosed and you query your SBOM database instead of manually inventorying dependencies. That’s when SBOM shifts from compliance checkbox to operational capability.
Start with a single service pilot. Generate SBOM, upload to Dependency-Track, configure alerts. When the first vulnerability alert arrives and you remediate it in hours instead of weeks, you’ll have your business case for organisation-wide rollout.
SBOM implementation is one component of a comprehensive supply chain security framework. Once you have continuous vulnerability tracking in place, you can expand to build integrity verification with SLSA, dependency management automation, and CI/CD pipeline hardening to establish defence-in-depth across your software delivery lifecycle.
Understanding Persistent Risk in Dependency Management and Why 95 Percent of Vulnerable Downloads Had Fixes AvailableHere’s something that should worry you: 95% of vulnerable component downloads already had fixes available when developers downloaded them. That’s right. Developers weren’t downloading vulnerable packages because patches didn’t exist. They were downloading them despite patches existing.
The 95% statistic isn’t about patch availability. It’s about process failure.
After SolarWinds and XZ Utils, your dependencies are the primary attack surface. As we explore in our comprehensive security approach, the question isn’t whether you’ve got vulnerable dependencies. It’s how long you’re leaving them unfixed and why.
This is where persistent risk comes in. It’s a framework from Sonatype combining unfixed risk (those unpatched vulnerabilities) with corrosive risk (the time-to-discover and time-to-remediate vulnerabilities hiding in old versions). Together, they tell you exactly how bad your dependency management process is.
In this article we’re going to walk through what persistent risk means, why that 95% statistic matters, how Log4Shell is still haunting 13% of downloads three years later, and how active dependency management with tools like Dependabot and Renovate reduces your risk by 7x.
Persistent risk is unfixed risk plus corrosive risk.
Unfixed risk refers to vulnerabilities within software components that have been identified but have yet to be addressed and in many cases will never be addressed. It’s straightforward. It’s known vulnerabilities sitting in your dependencies without patches applied. Every CVE scanner measures this. It’s those red alerts you’re ignoring.
Corrosive risk is the sneaky one. Corrosive risk impacts current and historical releases by incorporating the time needed to resolve vulnerabilities plus the delay in discovering vulnerabilities in old versions. It’s the time-to-discover vulnerabilities in old versions plus the time-to-remediate when you finally get around to updating. The older your dependencies get, the more likely they contain undiscovered vulnerabilities. And the harder they are to update because of breaking changes piling up.
Like metal corroding over time, old dependencies accumulate hidden weaknesses.
Traditional risk models only track unfixed risk. They tell you which CVEs exist right now. But they don’t tell you how exposed you are to future CVEs based on how old your dependencies are. They don’t quantify how hard it’ll be to fix those future vulnerabilities when version gaps are measured in years.
That’s why persistent risk matters. It captures both your current exposure (unfixed risk) and your future exposure (corrosive risk).
Unfixed risk gets measured by vulnerable components, severity scores, and exposure time. Every extra day a known CVE sits in production increases your risk.
Corrosive risk gets measured by dependency age. This is where the libyears metric comes in. Older dependencies correlate with more vulnerabilities because security researchers keep finding new CVEs in old code. And older dependencies are harder to update because version gaps keep getting wider.
The research is clear: persistent risk is driven by consumption practices, not open source quality. The best projects find and fix vulnerabilities quickly. Most downloads just aren’t of the fixed version.
That’s on you.
Sonatype found that 95% of vulnerable downloads already had fixes available at download time. This isn’t developers waiting for patches. This is developers choosing vulnerable versions despite available fixes.
Three root causes.
First up, complacent dependency management. The “set and forget” anti-pattern. Dependencies get pinned and never updated. No process for monitoring security advisories. Update cadence is quarterly or annual, if it exists at all.
Second, update friction without automation. The manual process doesn’t scale. Check the registry, test compatibility, merge the PR, deploy. Do that for 200 dependencies per project. High effort, high perceived risk. “If it works, don’t touch it” takes over.
Third, risk aversion creating update debt. Teams fear breaking changes from non-security updates. So they adopt “security updates only” policies. This creates large version gaps. The larger the gap, the harder updates become. Debt accumulates.
These three causes create worst-case exposure. Complacent management means high unfixed risk. Update debt means high corrosive risk.
Complacent dependency management results in risk that is seven times higher at 3.6% compared to 0.5% for active management. That 0.5% is the no path forward rate – components with no fixed version available.
The other 3.1% is complacency. Vulnerable components with available fixes that weren’t applied.
That gap from 0.5% to 3.6% is process failure. Your failure.
Libyears measures dependency age. For each dependency, you calculate the time between your current version and the latest version. Express it in years. Sum it across all dependencies.
Say your project uses React 16.8 (released February 2019). Latest is React 18.2 (June 2022). That’s 3.36 libyears. If you’ve got 50 dependencies with similar gaps, you could have 50+ libyears total.
Higher libyears correlate with more vulnerabilities. You are four times as likely to have security issues when you use outdated dependencies.
Libyears correlates with vulnerability density (older versions more likely to have CVEs), remediation difficulty (larger gaps mean more breaking changes), and maintenance signal (high libyears suggests complacent management).
Use libyears operationally. Calculate current libyears as a baseline. Set reduction goals. Track it as a process health metric. Prioritise updates for dependencies contributing the most libyears.
Libyears has limitations though. Age doesn’t equal vulnerable. Some old versions are still maintained. Use it alongside CVE scanning, not as a replacement.
Log4Shell (CVE-2021-44228) was disclosed December 9, 2021. CVSS 10.0. Remote code execution. Apache released a fix on December 10 – less than 24 hours later.
Thirteen percent of all Log4j downloads are still vulnerable versions nearly three years later.
Read that again. Three years. Non-breaking patches available within 24 hours. Mainstream media coverage. Government advisories. And 13% of downloads are still vulnerable.
The patch was a minor version bump from 2.14.1 to 2.15.0. No API breaking changes. Drop-in replacement. Clear upgrade guidance. This was as easy as security patches get.
The timeline tells the story:
December 10, 2021: Patch available.
January 2022: 80%+ of downloads still vulnerable.
June 2022: 50% still vulnerable.
December 2023: 25% still vulnerable.
December 2024: 13% still vulnerable.
This proves three things. High unfixed risk (13% didn’t patch despite availability), high corrosive risk (organisations using old Log4j likely have high libyears across all dependencies), and process failure (severity and publicity didn’t guarantee patching without proactive automation).
Despite Log4Shell being one of the most well-known vulnerabilities encountered in the last ten years, teams continue choosing known vulnerabilities.
If a CVSS 10.0 with non-breaking patches and global coverage still affects 13% of downloads three years later, what’s happening with medium-severity CVEs in your less-critical dependencies?
Active management reduces persistent risk by 7x compared to passive approaches.
Passive management is reactive. Updates get triggered by incidents or quarterly reviews. Process is manual. Cadence is infrequent and batched. Result: high unfixed risk plus high corrosive risk.
Here’s the passive pattern: scheduled “dependency update sprint” addressing months of debt. Teams find 50+ outdated dependencies. Half have breaking changes. Testing takes weeks. Something breaks. They learn: “dependency updates are risky and painful.” So they do it less frequently. The cycle reinforces itself.
Active management is proactive. Updates get triggered by automated monitoring and continuous PRs from bots like Dependabot or Renovate. Process is automated: bot creates PR, CI runs tests, human reviews if needed, merge. Cadence is continuous and incremental. Result: low unfixed risk plus low corrosive risk.
Here’s the active pattern: daily or weekly automated PRs with small version bumps. Tests run automatically. Most patch versions automerge if tests pass. Minor versions get reviewed weekly. Major versions get planned quarterly. Effort spreads out: 10 minutes per week instead of 40 hours per quarter.
Active management prevents update debt. Small gaps are easier to close than large gaps. Updating from 1.2.3 to 1.2.4 is low risk. Updating from 1.2.3 to 2.5.0 after two years is high risk.
Continuous testing catches breaking changes early. Effort gets spread out. Teams maintain familiarity with dependency changes.
You need a few things: automated testing (CI/CD with good coverage), merge policies (criteria for automerging patches, review cadence for minors, planning for majors), the tools (Dependabot or Renovate), and a cultural shift (trust automation, embrace continuous small changes).
The data backs this up. Mean-time-to-remediation: 2-7 days for active versus 60-180 days for passive. Lower update failure rate. Reduced corrosive risk.
Both tools automate the same workflow. Monitor package registries. Detect new versions and security advisories. Create pull requests. Run CI tests. Wait for review or automerge based on policies.
Repositories with automated dependency updates experience 40% fewer security vulnerabilities than those without automation.
Dependabot is GitHub’s built-in tool. Free. GitHub only. Configuration in .github/dependabot.yml. Security updates, version updates, grouped updates, scheduling (daily, weekly, monthly). Works with 14 package managers. Minimal configuration. Limitations: GitHub-only, less flexibility, basic scheduling.
Renovate is from Mend. Free for open source, freemium for private. Multi-platform: GitHub, GitLab, Bitbucket, Azure DevOps, Gitea. Configuration in renovate.json. All Dependabot features plus advanced scheduling (timezone-aware, business hours), sophisticated automerge policies, dependency dashboard, regex support. Works with over 30 package managers. Steeper learning curve, more complex configuration, higher flexibility.
Use Dependabot if you’re GitHub-only, want zero setup complexity, and basic scheduling works for you.
Use Renovate if you’re multi-platform, need advanced scheduling, want sophisticated automerge policies, or you’ll invest setup time for flexibility.
For most small to medium organisations on GitHub, Dependabot is the right choice. For complex requirements (monorepos, multi-platform), Renovate is worth it.
Either tool reduces persistent risk. The choice is about organisational fit, not security outcomes. For a complete dependency management tool comparison covering Snyk, open source alternatives, and decision frameworks, see our tool selection guide.
Applications (web apps, APIs, services) should pin exact versions. Always commit lockfiles (package-lock.json, Gemfile.lock, poetry.lock). Update via automation.
Why? Reproducible builds. Without exact versions and lockfiles, npm install on different days installs different versions. That’s untested code in production.
Libraries (published packages) should use semantic version ranges (^1.2.3 or ~1.2.3). Still commit lockfiles for development. Test against minimum and maximum supported versions.
Why? Downstream flexibility. If your library pins React to exactly 18.2.0, consumers can’t use it with React 18.3.0 without conflicts.
Patch versions (1.2.3 to 1.2.4): bug fixes and security patches. No breaking changes. Risk: very low. Strategy: automerge if tests pass. Cadence: continuous.
Minor versions (1.2.3 to 1.3.0): new features, backward compatible in theory. Risk: low (but breaking changes happen). Strategy: automated PR, human review, weekly merge.
Major versions (1.2.3 to 2.0.0): breaking changes. Risk: medium to high. Strategy: manual planning, changelog review, deliberate update. Cadence: quarterly or as needed.
Security updates always bypass the normal schedule.
End-of-life (EOL) components no longer receive security patches. EOL components indicate lack of dependency management. They signal systemic complacency.
EOL components require replacement, not updating. Check if the maintainer recommends a successor. Evaluate alternatives: community forks, foundation-backed projects, different approaches. Budget migration time like a major upgrade.
Dependabot and Renovate flag EOL versions automatically. Don’t ignore the warnings. EOL dependencies accumulate unfixed vulnerabilities indefinitely. No patches are coming.
Start with a pilot project. Choose one with 10-20 dependencies and good test coverage. Enable Dependabot or Renovate. Observe before rolling out broadly.
This transition isn’t just technical. It’s cultural. Teams need to shift from “if it works, don’t touch it” to “keep it current.”
Measure where you are. Calculate current libyears. Identify EOL components. Document your current update cadence.
Choose your tool. Dependabot for GitHub-only organisations wanting simplicity. Renovate for multi-platform or complex requirements.
Enable automation on the pilot. Configure schedules that won’t overwhelm. Daily security updates, weekly version updates. Set up dependency grouping.
Define criteria for automated merges versus human review. Patches passing CI automerge. Minors and majors need review.
Establish a regular PR review cadence. Weekly 15-minute standup or asynchronous. Consistency is key.
After 4-6 weeks, expand to additional projects. Monitor metrics: libyears decreasing, time-to-patch decreasing, PR merge rate increasing.
Plan full rollout over 2-3 months. Rushing creates resistance. Gradual expansion builds buy-in.
Success looks like: dependencies stay current (low libyears), patches deploy quickly (days not months), and your team spends less time on dependency management because automation handles the routine work.
Persistent risk is unfixed risk plus corrosive risk. The 95% statistic proves this isn’t a patch availability problem. It’s a process problem. Log4Shell persistence (13% still vulnerable three years post-patch) proves that severity and publicity don’t guarantee patching without proactive process.
Active management reduces risk by 7x compared to passive approaches. Dependabot (GitHub, simple, free) or Renovate (multi-platform, flexible, more complex) enable this shift.
The tooling exists. The patches exist. The evidence is clear.
Start today. Calculate libyears for your projects. Enable Dependabot or Renovate on one pilot project this week. Establish a regular review cadence. Measure and iterate.
Active dependency management isn’t a technical problem requiring new patches. It’s an operational problem requiring better processes. The question isn’t whether to implement it. The question is how quickly you can roll it out.
For a complete overview of supply chain security practices covering frameworks, threat landscape, and additional operational strategies, see our comprehensive guide.
Direct dependencies are packages you explicitly declare in your manifest file like package.json or requirements.txt. You chose them. You added them to your project.
Transitive dependencies are packages required by your direct dependencies. Dependencies of dependencies. You didn’t choose them directly, but your project needs them.
A project with 100 direct dependencies typically has 500+ transitive dependencies. That’s a 5x multiplier. Both Dependabot and Renovate monitor both types because vulnerable transitive dependencies compromise your application just as much as vulnerable direct dependencies.
Patch versions (1.2.3 to 1.2.4): automerge continuously if tests pass. These should only contain bug fixes and security patches.
Minor versions (1.2.x to 1.3.0): review and merge weekly in batches. These should be backward compatible but deserve human review because semantic versioning promises get broken.
Major versions (1.x.x to 2.0.0): plan deliberately with quarterly review sessions. These contain breaking changes requiring migration effort.
Security updates always bypass the schedule for immediate review. If a patch addresses a CVE, review it now.
Dependency confusion is a supply chain attack where an attacker publishes a malicious package with the same name as your private package to a public registry. Package managers may install the malicious public version instead of your private version.
Lockfiles prevent this by recording the exact registry source and cryptographic checksum for each dependency. When you run npm install with a lockfile present, npm installs exactly what the lockfile specifies, including which registry it came from. No substitution possible.
No. Automerge only patch versions that pass your CI test suite.
Patch versions (1.2.3 to 1.2.4) should contain bug fixes and security patches with no breaking changes according to semantic versioning. Configure Dependabot or Renovate to automerge these if tests pass.
Minor versions (1.3.0) and major versions (2.0.0) require human review because they can introduce breaking changes. Real-world packages break semantic versioning contracts regularly.
A lockfile (package-lock.json, Gemfile.lock, poetry.lock, go.sum) records the exact version of every dependency and transitive dependency installed, including cryptographic checksums.
Committing it ensures every developer and every CI/CD run uses identical versions. Without committed lockfiles, npm install run on Monday installs different versions than npm install run on Tuesday if any package published a new version in between.
This prevents “works on my machine” issues. Always commit lockfiles. Validate them in CI. Treat changes to lockfiles as significant.
End-of-life dependencies require replacement, not updating. No patches are coming. Vulnerabilities will accumulate indefinitely.
First, check if the maintainer recommends a successor package. Often this is noted in the README or a GitHub banner.
Second, evaluate alternatives. Look for community forks with active maintenance, foundation-backed alternatives, or different approaches to solving the same problem.
Third, budget migration time like you would for a major version upgrade. EOL migrations often require significant refactoring.
Tools like Dependabot flag EOL versions automatically. Don’t ignore these warnings.
Libyears measures your dependency age by summing the years between your current version and the latest version across all dependencies.
If you use React 16.8 (released February 2019) and the latest is 18.2 (June 2022), that’s 3.36 libyears for one dependency. Sum across all dependencies to get your project’s total.
Research shows projects with higher libyears have more vulnerabilities. Track libyears as a process health metric. Goal: less than 10 libyears per project, indicating active dependency management.
No. Running both simultaneously creates duplicate PRs and merge conflicts. Choose one based on your needs.
Dependabot for GitHub-only organisations wanting zero setup complexity. Renovate for multi-platform (GitLab, Bitbucket) or needing advanced scheduling.
Both reduce persistent risk equally when configured properly. The choice is about organisational fit, not security outcomes. Pick one, configure it well, and stick with it.
Start with a pilot project with good test coverage. Enable Dependabot or Renovate. Configure weekly scheduling. Observe PR volume for 2-3 weeks.
Establish automerge rules for patch versions that pass CI tests. Hold weekly review sessions for minor versions. After 4-6 weeks, expand to 3-5 more projects.
Track metrics: libyears (should decrease), mean-time-to-patch (should decrease), and update PR merge rate (should increase).
Full rollout takes 2-3 months as teams adapt to continuous small updates instead of large infrequent batches. The cultural shift from “if it works, don’t touch it” to “keep it current” takes time.
Vulnerability scanners (Snyk, GitHub Advanced Security, npm audit) identify CVEs in your current dependencies. They tell you what’s vulnerable. They don’t fix it.
Dependabot and Renovate both identify vulnerabilities AND create automated update PRs to fix them. Then they rerun after merging to verify remediation worked.
Think of scanners as detection tools. Think of Dependabot and Renovate as detection plus remediation automation.
For complete coverage, use both. Scanner provides comprehensive CVE database coverage. Dependabot provides automated updates.
Use this priority order:
First, patch immediately for critical CVEs with public exploits. These are emergencies.
Second, plan replacement for EOL components. No patches are coming. Risk accumulates daily.
Third, patch within 7 days for high-severity CVEs.
Fourth, reduce libyears by focusing on dependencies older than 2 years. These carry high corrosive risk.
Fifth, handle medium-severity CVEs and feature updates on normal cadence.
Configure Dependabot or Renovate to group related dependencies like all AWS SDK packages. This reduces PR count by 50-70%. Enable automerge for patches to eliminate manual review.
When Dependabot or Renovate creates a PR and your CI tests fail, you have three options.
First, investigate and fix if it’s a real compatibility issue. Update your code to work with the new dependency version.
Second, skip this version if it’s a known regression in the dependency. Wait for the next patch release. Close the PR with a note explaining why.
Third, pin temporarily if you need time to investigate. Add this version to your ignore list. Schedule follow-up work to either fix your code or find an alternative dependency. Don’t let temporary pins become permanent.
Tools won’t automerge failing tests. This is why good test coverage is a prerequisite for active dependency management. Tests catch breaking changes before production.
Foundation Support and Paid Maintainers Reduce Open Source Security Risk by 300 PercentIn February 2024, a lone, burnt-out volunteer was socially engineered over two years and nearly compromised every Linux SSH server on the internet. The XZ Utils backdoor didn’t happen because of technical oversight. It happened because of human sustainability failure.
Here’s what the data shows: maintainer sustainability is a supply chain security vulnerability. Foundation-supported projects show 4.1x higher vulnerability reporting, 94% higher fix rates, and fix things 264 days faster. Paid maintainer programmes deliver 3x fewer unfixed vulnerabilities.
This article is part of our comprehensive guide on software supply chain security, where we explore the evolving threat landscape and practical security frameworks. The data presented here demonstrates how governance models and maintainer compensation directly impact security outcomes. The conditions that enabled XZ Utils probably exist somewhere in your dependency chain right now.
Your software stack contains hundreds of open source components. A lot of them are maintained by unpaid volunteers working a burnout-inducing second shift after their day job.
The mechanics are straightforward. Maintainers burn out from unsustainable workloads while maintaining infrastructure the entire internet relies on. When Log4Shell hit, maintainers were working 22-hour days. For free. The Kubernetes External Secrets Operator saw contributions increase and support requests pile up while active members kept shrinking. The team was “mostly burnt out.”
By September 2024, ESO had one active maintainer left. When he went on vacation, zero pull requests merged and 20 issues opened. The project essentially shut down until five maintainers stepped up.
This is the bus factor problem. Single-maintainer projects create single points of failure. When one person burns out, your entire dependency chain is exposed. And when maintainers are burnt out they become susceptible to accepting help from malicious actors.
Most organisations don’t realise the scale of this. Modern software supply chain security depends on volunteers without formal security resources, governance, or succession planning. Every dependency increases your attack surface.
Burnout reduces code review quality. It slows vulnerability response. It creates social engineering opportunities that sophisticated attackers exploit.
As soon as maintainers burn out, supply chain attacks become easy. The only reason Log4Shell and XZ Utils didn’t cause catastrophes affecting hundreds of millions of people is they were discovered early. By luck, not process.
The XZ Utils backdoor was a three-year campaign. Between November 2021 and February 2024, an account using the name “Jia Tan” worked to gain control of the xz compression utility.
After pressure on the founder via apparent sock puppetry, Jia Tan gained co-maintainer status. Sock puppet accounts—Jigar Kumar, krygorin4545, misoeater91—pushed the lone maintainer to accept help. It worked.
In February 2024, a malicious backdoor was inserted into versions 5.6.0 and 5.6.1 of the liblzma library. The backdoor gave attackers with a specific private key remote code execution through OpenSSH on affected Linux systems. CVE-2024-3094 earned a CVSS score of 10.0. That’s the highest possible score.
Developer Andres Freund discovered it by accident. He noticed SSH connections generating unexpectedly high CPU usage—a 500ms latency anomaly—and errors in Valgrind. Discovery happened accidentally, not through security processes.
The attack succeeded because of human sustainability failure, not technical vulnerability. Foundation governance or paid maintainer support would have prevented the conditions that enabled this attack.
Multiple maintainers from different organisations would have made the sock puppet pressure campaign ineffective. Formal security processes would have caught the insertion. Professional infrastructure would have prevented a single burnt-out individual being the sole gatekeeper.
Computer scientist Alex Stamos noted this could have provided unprecedented access to hundreds of millions of computers running SSH. Had it remained undetected, it would have given its creators a master key to those systems.
The incident started discussion about infrastructure depending on unpaid volunteers. The foundation governance data shows how that translates into action.
Foundation-supported projects under Apache, Eclipse, and CNCF governance show measurably stronger security outcomes than independent projects.
They demonstrate 4.1x higher vulnerability reporting rates, 94% higher fix rates, and 264 days faster remediation. These aren’t marginal improvements. They represent structural advantages.
Foundation-supported projects are more likely to have multiple maintainers from different organisations. That reduces single points of failure. They show higher OpenSSF Best Practices badge certification rates. They maintain repository security features including branch protection and secure development standards compliance.
Foundation governance provides what independent projects typically lack: formal disclosure processes, dedicated security teams, multi-organisational contributor bases, and professional infrastructure.
Vulnerability reporting increases because foundations establish detection and disclosure infrastructure. Fix rates improve because dedicated resources and formal processes enable faster response. Remediation speeds up because professional infrastructure and coordinated capabilities reduce friction.
Foundation projects are more likely to implement formal vulnerability disclosure, CI/CD security integration, signed commits, and branch protection. They maintain up-to-date dependency management and security audits with vulnerability remediation records.
The governance mechanisms driving these outcomes include formal security teams, mentorship programmes, release management processes, and contributor diversity requirements. These mechanisms provide infrastructure that makes security sustainable.
Foundation projects demonstrate automated testing within CI/CD pipelines more consistently than independent projects. They show timely bug fixes and LTS support policies as part of their governance structure. They maintain recent activity within 12 months due to organisational backing.
Security assurance documentation and compliance with secure development standards come standard. Communication channels show active project engagement. These practices compound to create environments where security becomes systematic, not heroic.
Paid maintainer programmes deliver measurably better security outcomes by compensating developers for dedicated security work.
Compensated projects show 45% faster vulnerability resolution, 55% more security practices adoption, and 3x fewer unfixed vulnerabilities compared to unpaid counterparts.
The Tidelift model compensates maintainers directly for security work including vulnerability response, security practices adoption, and compliance documentation. This enables dedicated time for security work rather than sporadic volunteer effort.
These programmes complement foundation governance by filling the coverage gap for projects outside formal foundation structures.
Resolution speed improves because maintainers can allocate dedicated time to security work. Security practices adoption increases because compensation enables investment in tooling and processes. Unfixed vulnerabilities decrease because sustained attention replaces sporadic effort.
Paying maintainers helps companies safeguard the stability, security, and innovation keeping their products going. It enables maintainers to help companies comply with upcoming cybersecurity legislation. Companies that pay maintainers get competitive advantages attracting customers, employees, and contributors.
Investing in maintainer sustainability is sound financial risk management.
The Open Source Pledge establishes a minimum $2,000 per full-time equivalent developer per year corporate investment in maintainer sustainability.
Platforms like thanks.dev, Open Collective, GitHub Sponsors, and ecosyste.ms Funds facilitate payments to maintainers. Though open source contributors aren’t primarily motivated by money, people are more likely to contribute knowing they’ll be paid fairly. Supporting maintainer sustainability demonstrates commitment to supply chain security.
OpenSSF Scorecard is an automated security evaluation tool measuring open source project health. It examines security heuristics and assigns each a score between 0-10.
Scorecard maintains weekly scans of the 1 million most critical open source projects. Results are available through BigQuery’s public dataset. The tool lets you identify specific areas needing improvement and make informed decisions about accepting associated risks.
The OpenSSF Best Practices Working Group provides a systematic framework for assessing dependencies across six categories: necessity, authenticity, maintenance and sustainability, security practices, usability and security, and adoption and licensing.
Scorecard operates through multiple interfaces: a web-based viewer at scorecard.dev, a REST API for programmatic access, a GitHub Action for continuous monitoring, and a command-line interface for standalone usage.
It evaluates repositories across multiple security dimensions, producing individual check scores and an aggregate score reflecting overall security posture. The tool supports Docker containers, standalone binaries, package managers, and source compilation.
Key maintainer health signals include recent commits within 12 months, multiple maintainers from different organisations, formal security processes, and CI/CD integration. Current version stability indicators and established communication channels showing active project engagement matter.
Single maintainer with no succession plan. No activity in the past six to twelve months. No formal security process. No CI/CD integration. No signed releases. Declining contributor activity.
Every new dependency increases the attack surface. Assess necessity first. Confirm software authenticity by verifying it originates from authorised sources rather than unauthorised forks. Check for typosquatting through name verification and popularity assessment.
Security practices assessment should verify OpenSSF Best Practices badge certification, repository security features, existing security audits, compliance with secure development standards, and OpenSSF Scorecard ratings. Hands-on assessment includes behaviour testing in isolated environments, dependency bloat analysis, and code review for malicious patterns.
Individual check results contain false positives and negatives. Aggregate scores mask nuances about specific security behaviours. Scorecard isn’t one-size-fits-all. Multiple different practices can produce identical scores. Use it as one signal among many.
Dependency selection criteria should prefer foundation-governed projects, assess maintainer health before adoption, and require minimum Scorecard thresholds.
Dual-sourcing strategy means identifying alternative libraries for single-maintainer dependencies and maintaining migration capability. When a dependency is needed for your application, has limited maintainer support, and viable alternatives exist, have an exit plan.
Tiered dependency management classifies dependencies by usage. Apply stricter governance requirements to higher-risk tiers. Treat open source dependencies with the same rigour as commercial vendor assessments. Include maintainer sustainability in your evaluation criteria. For comprehensive strategies on managing dependency risk, see our guide on understanding persistent risk in dependency management.
Verify recent activity within 12 months, established communication channels, and current version stability. Prefer dependencies with multiple maintainers from different organisations to reduce single points of failure.
Assess security practices including OpenSSF Best Practices badge certification, repository security features, and up-to-date dependency management. Safe interfaces matter: verify security-conscious API design, interface stability supporting version upgrades, secure defaults in configuration, and clear security usage guidance.
Licensing clarity correlates with security practices. Require OSI-approved licences with consistent application. Assess popularity and real-world adoption patterns.
Internal sponsorship programmes allocate engineering time for upstream contributions to dependencies. This builds direct maintainer relationships. You learn the codebase. You establish communication channels. You reduce bus factor risk.
Vendor risk assessment for open source should mirror commercial assessments. Verify vulnerability reporting procedures. Establish automated testing within CI/CD pipelines. Verify known vulnerability status before accepting dependencies.
Update and monitoring cadence matters. Implement continuous vulnerability monitoring, automated dependency updates, and periodic maintainer health reassessment. Conduct hands-on assessment including behaviour testing, code review, and test suite validation.
Assess whether dependencies suit specific use cases rather than making hype-driven selections. Just because everyone uses it doesn’t mean it’s right for you.
Organisations reduce supply chain risk by actively supporting the open source ecosystem through corporate sponsorship, foundation membership, and engineering contribution programmes.
Companies should become members of the Open Source Pledge by paying maintainers at least $2,000 per FTE developer per year.
Corporate sponsorship mechanisms include GitHub Sponsors, Open Collective, thanks.dev, and ecosyste.ms Funds. Foundation membership provides direct financial support to Apache, CNCF, Eclipse, and Linux Foundation, enabling governance infrastructure.
Engineering contribution programmes allocate developer time for upstream security work, bug fixes, and documentation. If you want your business to continue leveraging innovative open source software, the most sustainable way is to pay the maintainers doing the innovating.
The EU Cyber Resilience Act sets minimum cybersecurity requirements that must be met before software is placed on the EU market. Compliance is required by December 2027.
By December 2027, companies will have to ensure both their internally authored software and the entire open source supply chain their software depends on complies with CRA regulations.
At least 50% of foundations report insufficient financial support to ensure CRA compliance. Open source foundations are your greatest ally in ensuring you comply with EU law, but they can’t do this without funding.
Organisations should collaborate with open source software stewards that take on certifying certain packages for CRA compliance. The most reliable way to ensure compliance is supporting foundations that can audit all packages you depend on and all packages they depend on.
The cost difference isn’t even close. The Equifax breach cost over $1.4 billion. Proactive investment in maintainer sustainability is cheaper.
Most organisations cannot answer basic questions about their dependencies’ maintainer health.
Maintainer burnout is becoming common. Without addressing maintainer sustainability, businesses will face zero-day security problems without warning or any clue how to address them.
How many vulnerabilities in industry-wide infrastructure are lurking undiscovered as maintainers burn out?
Quick diagnostic: How many of your dependencies have a single maintainer? When was the last commit? Is there a formal security disclosure process? Most organisations can’t answer these questions without investigation.
Assessment cost is trivial compared to supply chain incident cost.
Start with an OpenSSF Scorecard scan of your top 20 dependencies this week. Access Scorecard through any interface to scan your dependencies. Weekly scans of the 1 million most critical projects are already running—your job is to look at the results.
Use Scorecard to verify the maintainer health signals and security practices we’ve discussed above.
The systematic evaluation framework covers necessity, authenticity, maintenance, security practices, usability, and adoption. Use it.
The action framework: assess with OpenSSF Scorecard, select using dependency criteria, support through sponsorship, monitor with continuous evaluation.
This assessment cost is negligible compared to the cost of being wrong about your supply chain.
What is open source maintainer sustainability and why does it matter for security?
Maintainer sustainability refers to whether open source project maintainers have the resources, support, and compensation to continue their work long-term. It matters for security because burnt-out maintainers produce less secure code, respond more slowly to vulnerabilities, and become targets for social engineering attacks like the XZ Utils backdoor.
How much does it cost to sponsor an open source maintainer?
The Open Source Pledge recommends a minimum of $2,000 per full-time equivalent developer employed per year. Platforms like GitHub Sponsors, Open Collective, and thanks.dev facilitate payments. This is a fraction of the cost of responding to a single supply chain security incident.
What is the OpenSSF Scorecard and how does it assess project security?
OpenSSF Scorecard is an automated tool evaluating open source projects across multiple security dimensions, assigning scores between 0-10. It checks for branch protection, CI/CD integration, vulnerability disclosure processes, signed releases, and maintenance activity. It runs weekly scans of the 1 million most critical open source projects.
Can foundation support alone prevent supply chain attacks like XZ Utils?
Foundation support reduces risk but cannot eliminate it entirely. Foundation governance provides multi-maintainer requirements, formal security processes, and professional infrastructure that make social engineering attacks much harder. However, comprehensive supply chain security also requires build integrity frameworks, dependency monitoring, and organisational security practices.
What is the difference between foundation-supported and paid maintainer models?
Foundation-supported models like Apache, Eclipse, and CNCF provide organisational governance, legal protection, infrastructure, and community processes. Paid maintainer models like Tidelift and GitHub Sponsors provide direct financial compensation to individual maintainers. Both improve security outcomes through different mechanisms, and they’re complementary rather than competing approaches.
How do I know if my dependencies are at risk from maintainer burnout?
Key warning signs include: single maintainer with no succession plan, no commits in the past six to twelve months, no formal vulnerability disclosure process, no CI/CD integration, declining contributor activity, and open issues without responses. OpenSSF Scorecard automates many of these checks.
What did the XZ Utils backdoor (CVE-2024-3094) actually do?
The XZ Utils backdoor was a CVSS 10.0 vulnerability inserted through a multi-year social engineering campaign. It targeted the OpenSSH authentication process on Linux systems, potentially allowing unauthorised remote access. The attacker gained co-maintainer access by exploiting the original maintainer’s burnout and isolation.
How does the EU Cyber Resilience Act affect open source dependency management?
The CRA requires companies placing software on the EU market to ensure their entire supply chain, including open source dependencies, meets minimum cybersecurity requirements by December 2027. This creates a regulatory driver for supporting foundations and maintainers, as at least 50% of foundations report insufficient funding for CRA compliance work.
What is dual-sourcing for open source dependencies and when should I use it?
Dual-sourcing means identifying and maintaining migration capability to alternative libraries for dependencies, particularly those with single maintainers or uncertain sustainability. Use it when a dependency is needed for your application, has limited maintainer support, and viable alternatives exist.
How do foundation-governed projects achieve 264 days faster vulnerability remediation?
Faster remediation comes from multiple factors: formal vulnerability disclosure processes ensuring timely reporting, dedicated security teams or response coordinators, multiple maintainers available to develop and review patches, professional CI/CD infrastructure for rapid testing and release, and established communication channels for coordinated disclosure.
Hardening GitHub Actions Workflows from Mutable Tags to Runtime MonitoringIn early 2025, the tj-actions/changed-files GitHub action was compromised, exposing more than 15,000 repositories to a supply chain attack. The attack method was simple: the attacker replaced the v1 tag to point to a malicious commit. Every workflow using uses: tj-actions/changed-files@v1 suddenly started executing attacker-controlled code.
The root cause wasn’t some sophisticated zero-day exploit. It was a design choice most of us made without thinking – relying on mutable version tags instead of immutable commit SHAs.
Understanding software supply chain security in the context of CI/CD pipelines has become critical for any organisation running production workloads through GitHub Actions. If your workflows touch production credentials, deploy to cloud infrastructure, or publish packages, you’ve got the same vulnerability. The good news is hardening your workflows doesn’t require a massive security overhaul. You can migrate to commit SHA pinning in 1-2 weeks, configure OIDC authentication in 2-4 weeks, and layer on runtime monitoring without disrupting your existing pipelines.
Let’s walk through exactly how to do it.
GitHub Actions processes over 100 million workflows weekly across millions of repositories. That scale makes it a high-value target for supply chain attacks.
The default workflow configuration uses mutable tags like actions/checkout@v3. These are Git references that can be deleted and re-pointed to different commits. The tj-actions compromise proved this trust is misplaced.
Until February 2023, workflows ran with write permissions by default. A compromised action could push commits, create releases, or modify repository content. Even with more restrictive defaults now in place, many workflows still grant broad permissions.
CI/CD pipelines access production infrastructure, cloud provider APIs, and package registries. They’re sitting on AWS access keys, GitHub personal access tokens, and deployment credentials. Compromise a single popular GitHub Action and you get access to thousands of credential stores.
The attack timeline tells the story. SolarWinds in 2020 compromised the build system. Codecov in 2021 exfiltrated credentials via CI integration. The tj-actions attack in 2025 exploited mutable tags.
Developers implicitly trust actions from the actions/* namespace because GitHub publishes them. That trust often extends to third-party namespaces without scrutiny. Analysis shows 60% of popular actions use mutable dependencies, creating transitive risk even when you’ve hardened your workflows.
Commit SHA pinning replaces mutable tags with immutable 40-character commit hashes. Instead of actions/checkout@v3, you use actions/checkout@8e5e7e5a8f1e2a3b4c5d6e7f8a9b0c1d2e3f4a5b. The commit SHA is a cryptographic hash that can’t be changed or re-pointed.
Start by identifying all third-party actions in your workflows. Run grep -r "uses:" .github/workflows/ from your repository root.
For each action, navigate to its GitHub repository and locate the version tag you’re using. Click through to see which commit the tag points to. Copy the full 40-character commit SHA.
Now replace it. Change uses: tj-actions/changed-files@v40 to uses: tj-actions/changed-files@2d756ea93da014e7b7df225d13f5e6e43e5c2ee7 # v40.0.2. Notice the comment at the end. This maintains human readability while giving you immutability.
Test the workflow in a pull request branch before merging to main.
Don’t migrate everything at once. Start with workflows that have production deployment access – your highest risk targets (1-3 days). Then move to workflows that access secrets (4-7 days). Finally, handle read-only workflows (8-14 days).
Doesn’t commit SHA pinning break automatic security updates? No. Dependabot supports GitHub Actions updates.
Create .github/dependabot.yml in your repository:
version: 2
updates:
- package-ecosystem: "github-actions"
directory: "/"
schedule:
interval: "weekly"Dependabot will scan your workflows, identify commit SHA pins, check for newer versions, and open PRs with updated SHAs. Review and merge these weekly.
Branch protection rules enforce code review and status checks before merge. Someone can’t just push a change to .github/workflows/deploy.yml and compromise your production pipeline.
Configure branch protection on your main branch: “Require pull request reviews” (minimum one approval), “Require status checks to pass before merge”, and “Require signed commits”. Find these under Repository Settings → Branches → Branch protection rules.
Configure your CI workflow jobs as required checks. This forces security scans – secret scanning, dependency review, vulnerability checks – to pass before any code merges.
Tag protection rules prevent unauthorised tag deletion or re-pointing, which is exactly the attack vector used in the tj-actions compromise.
Set up tag protection: Repository Settings → Tags → Add protection rule. Use the pattern v* to match all version tags. Enable “Prevent tag deletion” and “Require signed tags”.
Create .github/CODEOWNERS and add .github/workflows/ @yourorg/security-team. This ensures any workflow changes require review from your security team.
For organisations with dozens of repositories, applying protection rules per-repository doesn’t scale. Use organisation rulesets instead. Go to Organisation Settings → Rulesets → New ruleset → Target “All repositories”.
Limit “Allow force pushes” and “Allow deletions” to break-glass administrator accounts with MFA enforcement.
OIDC (OpenID Connect) replaces long-lived AWS access keys with short-lived federated tokens issued per workflow run. Instead of storing AWS_ACCESS_KEY_ID in GitHub Secrets where it remains valid for 90+ days, you get temporary credentials that expire in 15-60 minutes.
Here’s how it works: GitHub Actions requests a JWT token, AWS STS validates that token against your trust policy, then issues temporary credentials scoped to the specific workflow run.
Setting this up on AWS involves three steps. First, create an OIDC identity provider in IAM. The provider URL is https://token.actions.githubusercontent.com and the audience is sts.amazonaws.com.
Second, create an IAM role with a trust policy that allows your specific GitHub repository. The trust policy condition: token.actions.githubusercontent.com:sub equals repo:yourorg/yourrepo:ref:refs/heads/main. Lock it down to specific repositories and branches.
Third, attach a least-privilege permissions policy. If your workflow deploys to S3, grant s3:PutObject for the specific deployment bucket. Don’t attach s3:* or AdministratorAccess. The most common mistake is attaching excessive IAM permissions because it’s easier.
On the workflow side, add permissions: { id-token: write, contents: read } to your job. Forgetting this causes the “OIDC token not found” error.
Then use aws-actions/configure-aws-credentials@e3dd6d6512e493a47ee3ea56a9890a770ddb8787 # v4 with the role-to-assume parameter pointing to your IAM role ARN.
Phase the migration: identify workflows using long-lived secrets (1-3 days), create OIDC providers and IAM roles (4-7 days), test in staging (8-14 days), roll out to production (15-21 days). Only after confirming OIDC works should you remove long-lived secrets – give yourself a 30-day rollback window.
Validate by verifying AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY are absent from repository secrets. Check CloudTrail logs for AssumeRoleWithWebIdentity API calls.
Harden-Runner from StepSecurity monitors GitHub Actions workflow execution at runtime, detecting anomalous behaviour that static analysis can’t catch. You can hash pin every action, configure perfect branch protection, and migrate to OIDC – but if a compromised action executes malicious code, none of those controls stop it. Runtime monitoring fills that gap – and contributes to SLSA build integrity requirements.
Add step-security/harden-runner@v2 as the first step in your job. Configure egress-policy: audit for monitoring mode or egress-policy: block for enforcement mode. Start with audit mode to establish a baseline.
Network monitoring tracks all outbound network calls. If your deployment workflow normally calls api.github.com, registry.npmjs.org, and s3.amazonaws.com, that’s your baseline. When a workflow suddenly calls attacker-controlled-domain.com, Harden-Runner alerts you. This is exactly how the tj-actions attack would have been detected.
File integrity monitoring detects modifications outside expected paths. If a workflow starts writing to /home/runner/.ssh/ for persistence, that triggers an alert.
Process monitoring identifies unexpected process execution. If a workflow that normally runs npm and AWS CLI suddenly spawns a cryptocurrency miner or reverse shell, that’s flagged immediately.
The correlation engine compares runtime behaviour against baselines from previous runs. Deviations – new network destinations, unusual file access patterns, unexpected processes – become potential compromise indicators.
Harden-Runner generates provenance attestation recording observed behaviour, contributing to SLSA Level 2 requirements.
Performance impact is minimal. Sub-second overhead per step, less than 2% measured across thousands of runs.
Deploy in audit mode for 2-4 weeks to establish baselines. Then enable block mode for highest-risk workflows – anything touching production infrastructure or handling secrets. After validating enforcement mode isn’t breaking legitimate workflows, expand to all workflows.
You need to know what you’re running. Inventory all third-party actions, assess maintainer health, review permissions, and identify high-risk dependencies.
Use the GitHub API to enumerate repositories and parse uses: directives across your organisation. The CLI approach is gh api /orgs/{org}/repos | jq '.[].workflows_url' but you’ll want to script this to fetch and parse workflow files.
Categorise by risk. Actions from the actions/* namespace are low risk – GitHub publishes them. Verified publishers are medium risk. Individual maintainers are high risk and require more scrutiny.
Assess maintainer health using OpenSSF Scorecard. This tool evaluates repositories across multiple security dimensions and produces a score from 0-10. For more detailed guidance on evaluating security tools and frameworks, see our supply chain security tool selection framework.
Set minimum acceptable scores. For workflows touching production or accessing secrets, require 7.0 or higher. For non-sensitive workflows, 5.0 is reasonable. Red flags: scores below 3.0, failed “Dangerous-Workflow” checks, or failed “Token-Permissions” checks.
actions/checkout scores 9.8, actions/setup-node scores 9.5. Many third-party actions fall in the 3.0-6.0 range.
Review the permissions each action requests. Flag excessive permission requests for manual review.
Check update frequency. Actions with the last commit more than 12 months ago might be abandoned. Consider replacing them with actively maintained alternatives.
Generate a compliance report showing what percentage of your actions use tags versus commit SHAs. Target 100% SHA adoption.
Set up a remediation workflow: any action scoring below 3.0 requires replacement or manual security review within 30 days. Either find a better-maintained alternative or perform your own security audit.
Hardening your workflows isn’t a one-time exercise. New actions get added weekly. Existing actions release updates. The threat landscape evolves. You need continuous maintenance.
Configure Dependabot to track GitHub Actions and auto-generate pull requests when new commits are available. Weekly schedule is reasonable.
If you’re on GitHub Enterprise, enable GitHub Advanced Security dependency alerts for actions with known vulnerabilities.
Run quarterly manual audits. Re-execute your third-party action inventory and OpenSSF Scorecard assessment. Track metrics – is your average Scorecard score improving?
Enforce CODEOWNERS review for .github/workflows/* changes. This ensures your security team has visibility into new action adoption.
Conduct developer training on secure workflow authorship semi-annually. Cover commit SHA pinning, minimal permissions, and proper secret handling.
Define an incident response runbook for suspected workflow compromise: disable GitHub Actions organisation-wide, rotate all secrets and credentials, audit CloudTrail and workflow run logs, perform forensic analysis, re-enable Actions once you’ve remediated the compromise. Having this written down before you need it saves time during an incident.
Track metrics: SHA pinning adoption percentage (target 100%), average OpenSSF Scorecard across all actions (target above 7.0), number of long-lived secrets in use (target 50% reduction through OIDC migration).
Enable secret scanning push protection to prevent developers from accidentally committing credentials. Use dependency review to block vulnerable action versions.
Subscribe to threat intelligence sources: GitHub Security Advisories (GHSA), StepSecurity threat reports, and Hacker News for emerging attack techniques. When new attack vectors are disclosed, assess whether your workflows are vulnerable and remediate proactively.
Review and update your organisation security policy annually. Security isn’t static – your policies shouldn’t be either. For a comprehensive overview of supply chain security strategies beyond GitHub Actions hardening, see our comprehensive guide to software supply chain security.
Semantic versioning tags like @v3 or @v3.5.2 are Git references that point to commits. They can be deleted and re-pointed to different code – that’s what enabled the tj-actions compromise.
Commit SHAs like @8e5e7e5a8f1e2a3b4c5d6e7f8a9b0c1d2e3f4a5b are cryptographic hashes. They’re immutable. You cannot modify them retroactively.
When you pin to a SHA, you guarantee that the exact same code executes every time. Best practice is to use the commit SHA with a version comment – @8e5e7e5a # v3.5.2 – so you get both security and readability.
No. Dependabot supports GitHub Actions and creates pull requests when new commits are available for your pinned actions.
Configure .github/dependabot.yml with package-ecosystem: "github-actions" and Dependabot will scan your workflows weekly, identify newer versions, and open PRs with updated commit SHAs. It preserves version comments automatically.
Yes. Major cloud providers support OIDC federation.
Azure uses Entra ID workload identity. You create a federated credential in your App Registration and configure the subject claim filter to match your repository.
Google Cloud offers Workload Identity Federation. Create a Workload Identity Pool and configure a provider with https://token.actions.githubusercontent.com as the issuer.
The workflow pattern is consistent: request a JWT from GitHub, exchange it with your cloud provider, receive temporary credentials scoped to your workflow run.
Pricing is $49 per active committer per month for GitHub Enterprise Cloud. For 100 committers, that’s $4,900 monthly.
You get secret scanning push protection, dependency review, code scanning with CodeQL, and the security overview dashboard.
An active committer is any developer who committed to a private repository in the last 90 days. Public repositories get these features free.
For smaller organisations, you can combine free features like Dependabot alerts and public repository scanning with third-party tools like StepSecurity or Snyk to get comparable coverage at lower cost.
When Harden-Runner is in block mode and detects a policy violation, your workflow fails. You’ll need to investigate and adjust your policy.
The recommended approach is running egress-policy: audit for 2-4 weeks to establish a baseline before enabling block mode. This identifies legitimate behaviour that needs to be whitelisted.
When you do get a false positive, review the StepSecurity dashboard to see what network call was blocked. If it’s legitimate, add it to your allowed endpoints in the workflow configuration.
If you need an escape hatch during production deployment, temporarily set egress-policy: audit for that specific workflow while you troubleshoot.
Private actions stored in internal repositories require different authentication than public Marketplace actions.
For actions in the same repository, use GITHUB_TOKEN with contents: read permission. For cross-repository access, use GitHub App installation tokens instead of personal access tokens.
Private actions bypass Marketplace security review entirely. Apply the same hardening standards you use for your workflows – commit SHA pinning, CODEOWNERS review, automated testing.
OpenSSF Scorecard ranges from 0 to 10, evaluating security practices like branch protection, dependency updates, and vulnerability disclosure.
For workflows touching production infrastructure or accessing secrets, require a minimum score of 7.0. For non-sensitive workflows, 5.0 is acceptable.
Red flags that should trigger immediate review: scores below 3.0, failed “Dangerous-Workflow” checks, or failed “Token-Permissions” checks.
Yes, if you have GitHub Enterprise.
Organisation rulesets let you apply branch protection, tag protection, and workflow permissions across all repositories. Go to Organisation Settings → Rulesets → New ruleset → Target “All repositories” and configure your required checks, signed commits, and permission defaults.
You can set organisation-level defaults for workflow permissions – permissions: read-all by default, requiring explicit write grants per workflow.
Free and Team plans only support repository-level policies. Organisation-level enforcement requires Enterprise.
Timeline depends on workflow complexity. Simple workflows take 1-2 hours each. Complex workflows with many dependencies might take 4-6 hours.
For 50 workflows, use a phased approach: inventory and prioritise (1 day), migrate the 10 highest-risk workflows (2-3 days), handle the remaining 40 workflows (5-7 days), and allocate 2-3 days for testing and validation.
Total duration is 10-14 days for an experienced team, or 15-21 days if you’re learning as you go.
You can script the SHA replacement to generate PRs automatically, which reduces manual effort to under an hour per workflow.
First mistake: overly permissive IAM trust policies that allow any repository in your organisation instead of locking down to specific repositories and branches.
Second mistake: attaching excessive IAM permissions like AdministratorAccess instead of least-privilege policies scoped to specific resources.
Third mistake: forgetting to add permissions: { id-token: write } to the workflow job, which causes “OIDC token not found” errors.
Fourth mistake: deleting long-lived secrets before validating OIDC works, creating a production outage if you need to roll back.
Prevention strategy: test OIDC in staging workflows first, validate CloudTrail shows AssumeRoleWithWebIdentity calls, and maintain secrets for a 30-day rollback window after migration.
The objection is valid – commit SHAs are unreadable. Developers can’t tell at a glance which version is pinned.
The solution is appending version comments: uses: actions/checkout@8e5e7e5a # v3.5.2. You get immutability with human readability.
Dependabot preserves these comments automatically when creating update PRs, so there’s no ongoing maintenance burden.
For the risk framing, show them the tj-actions incident timeline. Walk through how tag mutation works and why SHA pinning eliminates that entire attack vector.
Start with production deployment workflows – the highest risk, highest value targets. Once the team sees there’s no operational impact, expand to other workflows.
Yes, Harden-Runner supports self-hosted runners on Linux – Ubuntu, Debian, and RHEL.
Installation uses the same workflow configuration (step-security/harden-runner@v2). The monitoring agent installs on your runner during step execution.
Performance overhead is slightly higher on self-hosted runners – 1-3% CPU – compared to GitHub-hosted runners due to the instrumentation.
Network monitoring is particularly valuable for self-hosted runners with access to internal networks. You can detect lateral movement attempts that wouldn’t be possible from GitHub-hosted runners.
Windows and macOS self-hosted runners aren’t supported as of 2025. Linux only.
Implementing SLSA Build Integrity Framework for Software Supply Chain SecuritySoftware supply chain attacks have become the dominant enterprise threat vector, as explored in our comprehensive guide to supply chain security. The SolarWinds attack hit more than 18,000 organisations through one point of failure: the build pipeline. Attackers injected malicious code called Sunburst directly into the build process. Every customer who installed the update got compromised. It proved that build systems are the most consequential attack surface in modern software development.
SLSA (Supply-chain Levels for Software Artefacts, pronounced “salsa”) is the framework designed to prevent exactly this category of attack. It’s a structured maturity model from Level 0 (no guarantees) through Level 4 (two-party review with hermetic builds). Level 2? You can hit it in 2-4 weeks using existing hosted build services like GitHub Actions.
Governed by the OpenSSF and released as version 1.0 in April 2023, SLSA gives you a checklist of standards to prevent tampering and improve integrity in your software build processes. The steering committee includes Google, Chainguard, Intel, Datadog, and Microsoft.
SLSA targets threats to software supply chains that existing efforts like NIST SSDF don’t cover well. You get documentation, automated tooling, and in-depth guidelines to help you evaluate and communicate the security level of your software artefacts.
Google proposed SLSA in 2021 as a direct response to the SolarWinds breach. It’s based on security practices Google developed internally and has been developed in public since 2021. The OpenSSF now stewards it with governance from a diverse industry-wide group of specialists.
Build integrity means ensuring artefacts are built from intended source code without modification during compilation, packaging, or distribution. When your CI/CD system produces a Docker image or binary, you want proof that it came from your repository’s commit hash and nothing else touched it along the way.
That’s what SLSA provides through provenance attestation and progressive hardening of your build infrastructure. It’s a maturity model, not a binary pass/fail. You start where you are and work your way up the levels as your security posture improves.
The framework’s goals are to prevent tampering during the build process, maintain the integrity of package distribution systems, and safeguard build environments. It addresses the trust gap between source code review and the build process that transforms code into deployable artefacts. You might trust your source code reviews, but how do you know the build process hasn’t been compromised?
SLSA is a framework, not a certification. There’s no official SLSA certification body. Organisations self-assess their level based on the published requirements. Practitioners can self-evaluate or audit others using SLSA’s language to communicate security status.
The steering committee includes companies that have been burned by supply chain attacks or have the scale to worry about them constantly. They’re building a framework that works for organisations from 50 to 50,000 people.
SLSA gives you a progressive path. You don’t need to implement everything at once. Start with transparency at Level 1, add verification at Level 2, harden your builds at Level 3, and eventually reach maximum assurance at Level 4 if your threat model justifies it.
The levels progress from no guarantees through to maximum assurance with two-party review. Each level builds on the previous one, adding requirements that make tampering progressively harder. The SLSA version 1.0 release in April 2023 focuses primarily on the build track, with levels applied to source code, build systems, packaging, and dependencies.
Level 0 is the baseline. No SLSA requirements implemented. Most organisations start here. You’re building software, but you have no formal proof about how it was built.
Level 1 introduces provenance: the who, what, and how of the build process. The provenance includes the digest of the output artefact, dependencies used during the build, and build metadata like source repository and commit hash. But it’s unsigned. That means it’s just metadata anyone could forge.
Level 1 gives you transparency but not verification. You can look at the provenance and see what happened, but you can’t prove it wasn’t tampered with. Attackers with access to artefact metadata can modify it without detection. Level 1 doesn’t verify that dependencies are secure, meaning attackers could inject malicious dependencies.
Level 1 is designed to promote secure coding and prevent common mistakes like distributing incorrect packages. It’s a starting point that establishes visibility without adding security guarantees.
Level 2 requires digitally signed provenance by the build platform and dedicated, protected infrastructure. The signature makes it harder to forge or tamper with artefact metadata. This is where most teams should aim for their first year.
The signed provenance makes it significantly harder to forge or tamper with artefact metadata without detection. GitHub Actions, Google Cloud Build, and GitLab CI already satisfy the “dedicated build infrastructure” requirement. If you’re using hosted CI/CD, you’re probably closer to Level 2 than you realise.
Level 2 is a practical target representing a significant step towards secure software supply chain. But it doesn’t address threats from insiders or prevent tampering during the build itself, only after. It also doesn’t provide reproducibility guarantees, meaning the same inputs aren’t guaranteed to produce the same outputs.
Level 3 adds hardened builds with better isolation. Each build run is independent and executed in an isolated environment not affected by other processes. Secrets are protected from user-defined steps. This needs more sophisticated platforms like Tekton or equivalent systems with proper build isolation.
Level 3 provides tamper-resistant builds protecting from unauthorised changes. It offers reproducible builds where identical inputs always produce the same outputs. Secrets used to sign provenance data are protected from user-defined build steps.
The proposed Level 4 will focus on hermetic builds, hardware attestation, reproducible builds, and two-party review. Hermetic builds are entirely self-contained and 100% reproducible with no external factors like network access. All dependencies must be declared explicitly.
Two-party review means no single person can introduce code into production. At least two individuals review and verifiably sign off on change proposals before incorporation. This would have stopped the XZ Utils backdoor, which was a three-year campaign by a single maintainer who introduced malicious code in February 2024.
The backdoor got CVE-2024-3094 with a CVSS score of 10.0, the highest possible rating. It could have been the most widespread and effective backdoor ever planted in any software product, according to computer scientist Alex Stamos. Had it remained undetected, it would have given its creators a master key to hundreds of millions of computers running SSH.
Level 4 is where you go when nation-state actors are in your threat model. For most teams, it’s aspirational rather than practical. Achieving Levels 3 and 4 can be resource-intensive and complex, requiring significant changes to CI/CD pipelines and build environments.
Attackers compromised the build processes at SolarWinds, which let them issue a malicious update that looked legitimate. Malicious code was injected into the Orion platform on February 20, 2020.
The suspected nation-state hackers identified as Nobelium by Microsoft gained access to networks, systems, and data of thousands of SolarWinds customers. More than 30,000 public and private organisations use the Orion network management system. More than 18,000 installed the malicious updates.
The threat actors gained unauthorised access to SolarWinds network in September 2019 and tested initial code injection in October 2019. SolarWinds unknowingly started sending out Orion software updates with hacked code on March 26, 2020.
SLSA Level 2 would have detected the tampering through signed provenance verification. When deployment pipelines verify provenance before accepting artefacts, injected code without valid signatures gets rejected. The malicious update would have failed verification because it wouldn’t match the expected provenance from the legitimate build system.
SLSA Level 3 would have prevented the injection entirely through hardened, isolated build environments. With proper isolation, attackers can’t modify the build process even if they compromise other parts of the infrastructure.
The XZ Utils backdoor represents a different attack vector. An account using the name Jia Tan introduced a malicious backdoor to the Linux build of the xz utility in February 2024. The backdoor gives an attacker who possesses a specific Ed448 private key remote code execution through OpenSSH on affected Linux systems.
The campaign to insert the backdoor was the culmination of approximately three years of effort between November 2021 and February 2024. Jia Tan gained the position of co-maintainer through apparent sock puppetry and pressure on the founder. The backdoor was notable for its sophistication and high operational security practiced over a long period while working to attain a position of trust.
American security researcher Dave Aitel suggested it fits the pattern attributable to APT29, an advanced persistent threat actor believed to be working on behalf of Russian Foreign Intelligence Service. Microsoft employee and PostgreSQL developer Andres Freund discovered the backdoor on March 29, 2024.
SLSA Level 3 protections and recursive SLSA audits provide some protection from XZ-style attacks. SLSA Build Level 4 would increase protection through hermetic builds and two-person review requirements that would prevent a single maintainer from introducing malicious code.
SLSA and SBOM are complementary, not competing. SLSA answers “was this built correctly?” while SBOM answers “what is inside this?”
SLSA proves build integrity: that artefacts were built correctly from intended sources without tampering. SBOM provides component transparency: a complete inventory of what’s inside a software artefact. You need both.
A software bill of materials is like a “nutritional label” on packaged food products, clearly showing what’s inside a product. By maintaining an SBOM, organisations can identify security risks, manage third-party dependencies, and strengthen supply chain security.
The Biden Administration mandated SBOMs in May 2021 through executive order. Many organisations implemented SBOM first because of regulatory pressure. That’s fine. SBOM gives you visibility into your dependencies, which helps when vulnerabilities are disclosed.
But SBOM without SLSA means you have an inventory you can’t verify. Someone could tamper with your build, and your SBOM would still show the legitimate components. SLSA provenance can include SBOM as part of build attestation, creating a verified inventory you can trust.
Regulations like the U.S. Executive Order on Cybersecurity and NIST guidelines now mandate SBOM usage for software providers. Those who operate software can use SBOMs to quickly determine whether they are at potential risk of a newly discovered vulnerability.
If you’re starting fresh, implement SBOM first for compliance, then add SLSA for integrity. If you already have SBOM, SLSA is your next step. Our SBOM implementation roadmap covers how these complementary transparency frameworks work together. Integrate SBOM generation into CI/CD pipeline to automate creation as part of development, ensuring real-time visibility. Use SBOM data to continuously assess third-party risks, flagging components with known vulnerabilities.
Level 2 is an achievable year-one goal for most teams. You don’t need to build custom infrastructure or hire a security team. The tooling already exists and most of it is free.
GitHub Actions, Google Cloud Build, or GitLab CI already satisfy the “dedicated build infrastructure” requirement. If you’re using hosted CI/CD, you’re already running builds on dedicated, protected infrastructure. That’s half of Level 2 done.
The other half is signed provenance. This is where Sigstore removes the traditional barrier of key management infrastructure. Keyless signing via OIDC means you don’t need to generate, store, rotate, or protect cryptographic keys. The signing uses ephemeral keys and OIDC identity tokens, and the signing event is recorded in Rekor, a public transparency log.
Tooling cost is minimal. GitHub Actions provides native SLSA provenance support at no additional charge. Sigstore is free and open source. The primary investment is engineering time: approximately 2-4 weeks for implementation and integration.
Most teams already using CI/CD are closer to Level 2 than they realise. You’re not rebuilding everything from scratch. You’re adding provenance generation and verification to your existing pipeline.
SLSA is designed with ease of adoption in mind. Moving up through Build track levels should feel minimally invasive. SLSA advocates for evaluating each software artefact independently without endorsing transitive trust.
Companies may use SLSA to assess their internal infrastructure, highlight security status, and identify gaps. Don’t aim for the highest level right away. Build incrementally to avoid disruption while achieving meaningful security improvements.
Not all organisations have the infrastructure or technical maturity to implement advanced security practices at Levels 3-4. Start where you are. Level 2 provides significant security value for most threat models.
The implementation follows a straightforward pattern: audit what you have, add provenance generation, add verification. For detailed guidance on implementing SLSA with GitHub Actions, see our comprehensive hardening guide that covers the hosted build platform for achieving SLSA Level 2.
Confirm your builds run on hosted infrastructure like GitHub Actions, GitLab CI, or Google Cloud Build. Check that builds don’t run on developer laptops or unmanaged servers. Hosted infrastructure gives you the dedicated, protected environment Level 2 requires.
Identify all build pipelines producing deployable artefacts. Document your build process. What triggers builds? Where do artefacts get stored? What’s the deployment pipeline? You need this map before you add provenance.
Ensure build environment follows SLSA standards and is protected from unauthorised access. Use dedicated build infrastructure and avoid builds on developer workstations. Regularly audit and update build tools to prevent vulnerabilities.
Add slsa-github-generator to your GitHub Actions workflows. This generates provenance attestations that include the output artefact digest, dependencies, and build metadata.
Configure provenance metadata including source repository, commit hash, and build parameters. Identify build artefacts and automatically generate, log, and distribute standardised provenance metadata.
Set up Sigstore cosign for keyless signing using OIDC identity tokens. The signing happens automatically as part of your build workflow. No key management required.
Sign provenance data, attestations, and artefacts with cryptographic signatures for integrity validation. Secure and centralise the build process ensuring auditability and tamper resistance.
Verify the provenance is being generated successfully. Check the workflow logs and confirm attestations are created and signed for each build. Standardise and document all build processes for auditability.
Add provenance verification to deployment pipelines. This is where SLSA provides security value. Generating provenance without verifying it defeats the purpose.
Reject artefacts without valid signed provenance. Make this a hard gate. If the signature doesn’t verify, the deployment fails. Verification must happen where deployment decisions are made, not just where builds run.
The common pitfall is not verifying provenance at deployment time. Teams implement generation because it’s technically interesting, then forget to enforce verification. That leaves you with transparency but no security.
Monitor the supply chain to detect inconsistencies. Before implementation, builds have unknown origin and no tamper detection. After implementation, builds have verified source and are tamper-evident.
SLSA provenance verification uses Sigstore cosign to validate attestations. The verification checks the signature matches the expected identity and the provenance matches the artefact digest.
Use cosign verify-attestation to check provenance against expected values like source repo, builder identity, and build platform. Verification mechanics require checking certificate identity and OIDC issuer.
Verification should occur at every deployment gate. Before an image gets deployed to staging, verify it. Before it goes to production, verify it again. Treat unsigned or unverified artefacts as compromised.
All signatures are recorded in Rekor transparency log providing an immutable audit trail. Provenance includes builder ID, build type, invocation config source, and materials (dependencies).
Policy enforcement with tools like Kyverno can prevent deploying images without valid provenance at the cluster level. This gives you defence in depth. Even if someone bypasses your deployment pipeline, Kubernetes won’t run the artefact.
Monitor provenance generation success rates. You want 100% of builds generating valid signed provenance. Track verification failures separately. Failures might indicate attacks, or they might indicate configuration problems. Either way, you need to know about them.
Track SLSA compliance with monitoring alerts for images without provenance. Maturity indicators include percentage of artefacts with valid provenance, mean time to detect provenance failures, and verification coverage across deployment targets.
After you achieve Level 2, plan a 1-3 year progression to Level 3. Level 3 requires build isolation that platforms like Tekton provide. This is a bigger infrastructure change than Level 2, so you need time to plan, test, and migrate.
The timeline depends on existing infrastructure maturity, team expertise, and the number of build pipelines requiring migration. Level 3 requires hardened build platforms with regular audits and updates ensuring documentation authenticity. It requires automating validations and checks to prevent tampering.
Most teams should stay at Level 2 for at least a year while they mature their verification processes and build confidence in the system. Level 3 makes sense when you have the engineering resources to manage more complex infrastructure and your threat model justifies the investment.
Implementing SLSA will be a continual effort. Regularly review progress and watch for developments in specifications. Adapt security strategy to match the standards as they change to ensure software supply chain remains resistant to emerging threats.
SLSA provides the build integrity foundation for a complete supply chain security strategy. For a broader understanding of frameworks, practices, and tools across the entire security landscape, see our software supply chain security overview.
How do you pronounce SLSA?
SLSA is pronounced “salsa” like the condiment or the dance. It stands for Supply-chain Levels for Software Artefacts.
Is SLSA a certification or a framework?
SLSA is a framework, not a certification. There’s no official SLSA certification body. Organisations self-assess their level based on the published requirements.
What does it cost to implement SLSA Level 2?
The tooling cost is minimal to zero. GitHub Actions provides SLSA support at no additional charge, and Sigstore is free. The main cost is engineering time: 2-4 weeks for implementation and integration.
Can you implement SLSA without Sigstore?
Yes, but you’ll need to manage cryptographic keys yourself. Sigstore removes the key management burden through keyless signing with OIDC. You can use traditional signing with long-lived keys, but that adds operational overhead.
Do I need both SBOM and SLSA?
Yes. SBOM gives you component transparency, SLSA gives you build integrity. They’re complementary frameworks that address different aspects of supply chain security.
Which CI/CD platforms support SLSA provenance generation?
GitHub Actions, Google Cloud Build, and GitLab CI all support SLSA provenance generation. GitHub Actions has native support through slsa-github-generator.
How long does it take to progress from Level 2 to Level 3?
Plan for 1-3 years depending on your infrastructure and resources. Level 3 requires more sophisticated build platforms with proper isolation, which is a larger infrastructure change.
What is keyless signing and how does it work?
Keyless signing uses ephemeral keys and OIDC identity tokens instead of long-lived private keys. The signing event is recorded in Rekor, a public transparency log, providing verification without key management overhead.
Responding to the tj-actions GitHub Actions Compromise and Preventing Tag-Based Supply Chain AttacksIf your repositories used tj-actions/changed-files at any point, you need to act now. In March 2025, security researchers found that every version tag of this popular GitHub Action had been redirected to malicious code that dumped secrets into workflow logs. AWS keys, GitHub tokens, npm credentials—all sitting there in plaintext for anyone with read access to see.
The attack exploited how most teams reference GitHub Actions. It demonstrates a weakness in the ecosystem: teams pin to mutable tags instead of immutable commit SHAs. This incident exemplifies the broader challenges we explore in our software supply chain security guide, where CI/CD pipelines have become primary attack vectors.
So here’s what you need to do: work out if you’re affected, rotate any exposed credentials, and fix your workflows so this can’t happen again. This article walks through the incident response process and the preventive controls that actually work.
On March 14, 2025, security vendors including Wiz, Step Security, and Checkmarx reported that tj-actions/changed-files contained malicious code designed to steal secrets from CI/CD runners. This action helps developers detect which files changed in a pull request, and it’s embedded in over 23,000 repositories.
The attack redirected every version tag—v1 through v45—to a single malicious commit. When workflows ran, the compromised code scanned runner memory for sensitive data and dumped it into workflow logs. Anyone with access to those logs could read the secrets.
CVE-2025-30066 was assigned to this incident. While approximately 218 repositories actually exposed secrets during the compromise window, the potential impact was way bigger because tj-actions/changed-files was so widely deployed.
The attack exploited a trust model weakness in how the ecosystem references GitHub Actions. Workflow logs are readable by anyone with repository access—and publicly accessible on public repos—so the exfiltration happened through workflow logs.
The attack started weeks earlier when adversaries compromised the reviewdog GitHub organisation. They targeted the reviewdog/action-setup action and related tools to steal credentials, including a GitHub Personal Access Token belonging to a tj-actions maintainer.
With that PAT, attackers performed what’s called tag mutation. They redirected every existing version tag in tj-actions/changed-files to point to a malicious commit. Because most users referenced version tags instead of immutable commit SHAs, tens of thousands of workflows unknowingly pulled the attacker’s code.
The attack chain followed this sequence: reviewdog PAT theft, tj-actions tag mutation, runtime memory dumping on CI/CD runners, then log-based exfiltration. Each stage looked legitimate in isolation, which is why it was so hard to detect.
This upstream-to-downstream cascade is a hallmark of supply chain attacks: compromise one trusted component to reach all its dependents. This pattern mirrors the build system compromise attacks where adversaries targeted CI/CD infrastructure to inject malicious code at scale. The reviewdog compromise (CVE-2025-30154) gave attackers the access they needed. tj-actions became the delivery mechanism.
The malicious code used runtime memory dumping to extract secrets from the runner’s process memory and environment variables. It bypassed GitHub’s standard secret masking by encoding credentials in a way the redaction system didn’t catch. The secrets appeared in logs in unredacted form, accessible to all users with read access.
Once executed, the malicious code scanned the GitHub runner’s memory for AWS keys, personal access tokens, npm tokens, and private keys. It dumped these secrets into the workflow logs, exposing them to anyone with repository access.
Here’s what was at risk: GitHub secrets injected into environment variables, the GITHUB_TOKEN, cloud provider keys for AWS, Azure, and GCP, npm and PyPI tokens, RSA private keys, and any other sensitive data in the runner’s process memory.
On public repositories, this exposure was visible to the world. On private repositories, anyone with read access could view the logs.
What this meant for you depended on what types of secrets were exposed. Leaked cloud provider credentials could enable infrastructure access. Leaked deployment tokens could enable supply chain attacks on your customers. Even read-only tokens created risk, though lower than write-capable credentials.
The affected actions weren’t limited to tj-actions/changed-files. The compromise also hit reviewdog/action-setup, reviewdog/action-shellcheck, reviewdog/action-composite-template, reviewdog/action-staticcheck, reviewdog/action-ast-grep, reviewdog/action-typos, and tj-actions/eslint-changed-files.
If you used any of these in your workflows, assume any secret or sensitive information that workflow accessed has been leaked to all users with read access to the repository.
Start by inventorying all repositories in your organisation that reference tj-actions/changed-files in any workflow file. These live in .github/workflows/ directories in files with .yml or .yaml extensions.
Use GitHub’s code search or the Checkmarx detection tool to identify repositories that used the action during the compromise window. Transitive relationships matter. If an otherwise-safe action uses the malicious action, you’re still at risk.
Examine workflow run logs from the affected period for indicators of compromise. Look for unusual output patterns, base64-encoded content, or exposed credential values. The free, open-source tool “2MS (Too Many Secrets)” from Checkmarx Zero can help you quickly identify secrets in downloaded log files.
Check GitHub audit logs for any unusual API activity that might indicate stolen credentials were already exploited. When attackers target public repositories as entry points and those repositories serve as dependencies for thousands of downstream projects, their compromise provides immediate access to hundreds of potential targets.
And don’t forget to check both current and historical workflow configurations. You may have removed the action already, but logs from the compromise window still contain exposed secrets.
Priority one: rotate all secrets that were available to any workflow using tj-actions/changed-files. This includes GitHub PATs, cloud provider credentials, deployment tokens, npm/PyPI tokens, and any other secrets configured in repository or organisation settings.
If you have public repositories that use one of the compromised actions, assume that any secrets used in GitHub Workflows for those repositories have been leaked and should be rotated. For internal or private repositories, be aware that secrets may have been leaked to any user with any level of access.
Priority two: replace tj-actions/changed-files with a verified alternative. Step Security provides step-security/changed-files as a drop-in replacement. Or you can use native Git commands within your workflow to detect changed files.
Whatever replacement you choose, pin it by commit SHA rather than tag to prevent the same class of attack.
Priority three: review GitHub audit logs and cloud provider access logs for evidence of credential misuse during and after the compromise window. Look for API calls, resource access, or configuration changes you don’t recognise.
Priority four: if your organisation publishes packages or actions that may have been built with compromised credentials, notify downstream consumers. They need to know their supply chain may be affected.
Priority five: document the incident scope and response actions for compliance and post-incident review. Record the timeline, affected systems, response actions, and lessons learned.
You may also need to restrict access to GitHub repositories temporarily, changing public repositories to private or internal for your organisation until you complete the audit and credential rotation.
The primary defence against tag mutation attacks is commit SHA pinning. Reference GitHub Actions by their full 40-character immutable commit hash rather than mutable version tags. For a comprehensive approach to securing your CI/CD environment beyond immediate incident response, see our comprehensive GitHub Actions hardening guide.
SHAs are immutable. Tags aren’t. An attacker who compromises an action’s repository can simply move the v4 tag to point to malicious code, instantly affecting every workflow using that tag.
In August 2024, GitHub announced policy support for blocking and SHA pinning actions. Administrators can now enforce SHA pinning through the allowed actions policy. Any workflow that attempts to use an action that isn’t pinned will fail.
Because this is a new policy, GitHub administrators must explicitly opt in. Tools available to perform the pinning include gh-pin-actions extension for the GitHub CLI and RenovateBot.
Once pinned, Dependabot will automatically submit pull requests with the correct new commit SHA when updates are available. Use Dependabot or Renovate to automate SHA-pinned dependency updates so security doesn’t come at the cost of maintenance burden.
Migrate from stored long-lived credentials—PATs, service account keys—to OIDC-based authentication for cloud provider access. OIDC provides short-lived, scoped authentication tokens generated at runtime rather than stored secrets. These tokens are generated on-demand and expire quickly. Because OIDC tokens aren’t stored in GitHub secrets or environment variables, they can’t be exfiltrated through log dumping. All major cloud providers support OIDC integration with GitHub Actions.
Scope GITHUB_TOKEN permissions to the minimum required for each workflow using explicit permissions blocks. Set permissions to read-only by default, and grant write only when necessary. Repositories created before February 2023 likely still have overprivileged GITHUB_TOKEN defaults with read/write permissions, while newer repositories default to read-only.
Implement a third-party action audit process. Review the action’s source code for suspicious behaviour—network calls, environment variable access, log output. Check the maintainer’s reputation, contribution history, and responsiveness to security issues. Verify the action’s dependency graph for transitive risks. Assess the permissions the action requires and whether they follow least privilege principles.
Store secrets in environment secrets instead of repository secrets. Secrets defined at the repository level are accessible to all workflows with no way to limit access. Environment secrets let you set branch policies to limit which branches have access, and you can require manual approval for production keys.
And here’s a blanket rule: don’t rely on pull_request_target. This trigger runs workflow code with write permissions in the context of the base repository, even when triggered by pull requests from forks. This enables “pwn request” attacks where malicious pull requests can execute arbitrary code with elevated privileges. For most scenarios, the pull_request trigger is sufficient.
The tj-actions compromise demonstrates that CI/CD pipelines are now high-value targets for attackers, not just infrastructure to keep running. You might secure your production systems carefully, then hand the keys to your kingdom to YAML files you barely audit, using actions from strangers on the internet, triggered by events you don’t fully control.
Tag-based supply chain attacks exploit a trust model weakness: the assumption that a version tag always points to the same code. The attack pattern of compromising upstream maintainers to reach downstream targets mirrors tactics seen in the SolarWinds and XZ Utils incidents, suggesting you’re facing a persistent and evolving threat category.
The breach resulted from four misconfigurations colliding: weak event triggers, excessive permissions, mutable dependencies, and poor runtime isolation. If any one of these controls had been enforced—least-privilege tokens, SHA pinning, secret scanning, or ephemeral runners—the attack chain would have broken.
Building resilience requires defence in depth. No single control is sufficient alone, but together SHA pinning, OIDC, permission scoping, and audit procedures reduce the attack surface. These preventive controls are detailed in our hardening GitHub Actions workflows article, which covers implementation specifics for long-term CI/CD security.
You need a dependency governance policy that covers not just application packages but also CI/CD tooling, build actions, and deployment scripts. As attackers increasingly target GitHub Actions, organisations must move beyond reactive security measures. Combine webhook monitoring with audit log analysis to establish visibility into your CI/CD pipeline risks.
As we’ve seen with compromises like this, attackers are investing time to understand your supply chain. It’s time to invest equally in understanding and monitoring your attack surface. For a complete security strategy covering frameworks, operational practices, and tool selection across your software supply chain, see our broader security context guide.
CVE-2025-30066 refers to the tj-actions/changed-files compromise. It’s critical for any organisation that used the action during the compromise window, as it could expose cloud credentials, deployment tokens, and other sensitive secrets.
Tag mutation attacks exploit the mutable nature of Git tags. An attacker with repository write access can silently redirect a tag like v1 or v45 to point to a malicious commit. Traditional supply chain compromises typically involve injecting malicious code into a new release. Tag mutation is stealthier because no new version is published—the existing trusted version silently changes.
SHA pinning references an action by its full 40-character commit hash, which is immutable and always points to the exact same code. Tag references like @v4 are mutable and can be redirected to different commits by anyone with write access to the repository. SHA pinning prevents tag mutation attacks but requires tooling to manage updates.
Yes. If any repository in your organisation used tj-actions/changed-files during the compromise window, treat all secrets available to those workflows as potentially exposed. The cost of unnecessary rotation is far lower than the risk of compromised credentials being exploited.
OIDC provides short-lived, scoped authentication tokens generated at runtime rather than stored as long-lived secrets. Because OIDC tokens aren’t stored in GitHub secrets or environment variables, they can’t be exfiltrated through log dumping. Major cloud providers support OIDC integration with GitHub Actions.
Review the action’s source code for suspicious behaviour like network calls, environment variable access, and log output. Check the maintainer’s reputation, contribution history, and responsiveness to security issues. Verify the action’s dependency graph for transitive risks. Assess the permissions the action requires and whether they follow least privilege principles.
The pull_request_target trigger runs with the permissions of the target branch even when a PR is opened from a fork, granting access to repository secrets. This makes it particularly dangerous when handling untrusted contributions. For most scenarios, the pull_request trigger is sufficient.
The malicious code bypassed GitHub’s process for redacting secrets from run logs by encoding them in ways the masking system didn’t recognise. Secret masking is a useful layer but shouldn’t be relied upon as the sole defence. Combine it with OIDC, permission scoping, and SHA pinning for comprehensive protection.
The reviewdog compromise (CVE-2025-30154) was the initial stage of the attack. Attackers compromised the reviewdog organisation’s actions to steal a GitHub PAT belonging to a tj-actions maintainer. That stolen PAT was then used to mutate all tj-actions/changed-files tags to point to malicious code. The reviewdog compromise was the enabler; tj-actions was the delivery mechanism.
Step Security provides step-security/changed-files as a drop-in replacement. Or you can use native Git commands within your workflow to detect changed files. Whatever you choose, pin it by commit SHA rather than tag to prevent the same class of attack.
Use the GitHub API to retrieve workflow run logs from the compromise window. Scan them with the Checkmarx 2MS scanner or TruffleHog for patterns indicating exposed credentials—base64-encoded strings, key formats matching cloud providers, token patterns. Pay attention to any unusual output that doesn’t match expected workflow behaviour.
Self-hosted runners can provide more control over the execution environment but introduce different risks: persistent state between runs, network access to internal resources, and longer credential exposure windows. Unlike GitHub-hosted runners that are destroyed after each job, self-hosted runners persist and can be permanently compromised. Neither runner type is inherently safer; each requires specific hardening.