Software supply chain security checklist: 9 best practices

Key takeaways

• Software supply chain security covers far more than dependency scanning. A complete program needs controls for dependencies, software bills of materials (SBOMs), AI components, secrets, CI/CD pipelines, containers, package registries, infrastructure as code (IaC), runtime applications, and third-party software.
• OWASP Top 10:2025 reflects this broader scope with A03:2025 Software Supply Chain Failures, which covers breakdowns and compromises in how software is built, distributed, and updated.
• Recent incidents show how supply chain attacks can move through trusted packages and build infrastructure. Shai-Hulud spread between npm packages using stolen credentials, while the Trivy compromise demonstrated how a trusted CI/CD security tool could become an entry point for further compromise.
• Software composition analysis (SCA) and SBOMs provide component visibility, while dynamic application security testing (DAST) examines the assembled, running application from an attacker’s perspective. These approaches answer different security questions and are most useful when their findings can be correlated and prioritized together.
• The Invicti Application Security Platform brings SCA, SBOM management, secrets detection, IaC and container security, DAST, API security, and application security posture management (ASPM) into a unified workflow, with runtime intelligence providing additional context for prioritization.

Modern software is assembled from far more than first-party source code. Applications can depend on hundreds of open-source packages, container base images, GitHub Actions, CI/CD workflows, cloud credentials, infrastructure templates, APIs, AI models and services, build tools, and third-party software.

Every dependency and integration introduces a trust relationship. Attackers increasingly look for ways to abuse those relationships instead of attacking an application directly.

OWASP formally broadened its treatment of this risk in the Top 10:2025. A03:2025 Software Supply Chain Failures covers compromises and breakdowns in the processes used to build, distribute, and update software, including third-party components, repositories, development tooling, and artifact creation.

The practical consequence is that a software supply chain security checklist cannot stop at SCA or SBOM generation. Teams need layered controls from dependency selection and build infrastructure through deployment and runtime testing.

This checklist covers nine areas that AppSec and DevSecOps teams should address.

What is software supply chain security?

Software supply chain security is the set of practices and controls used to protect the components, tools, identities, infrastructure, and processes involved in building and delivering software.

The software supply chain can include:

• Open-source dependencies and transitive dependencies
• Third-party libraries and services
• AI models, datasets, frameworks, and external AI services
• Package registries
• Source code repositories
• Build tools and CI/CD pipelines
• Developer and service identities
• Secrets and publishing credentials
• Container images
• Infrastructure-as-code files
• Deployment artifacts
• Vendor software
• Running applications and APIs

Securing this chain requires both preventive controls and ongoing verification. Static and build-time techniques can identify vulnerable components, exposed secrets, and configuration problems before deployment. Runtime testing adds another perspective by examining the application that is actually assembled and exposed.

The nine software supply chain security control categories

Best practice 1: Manage dependencies and open-source risk

Open-source components accelerate development, but every dependency can introduce security, maintenance, and licensing risk.

That risk is not limited to known Common Vulnerabilities and Exposures (CVEs). Common supply chain attack patterns include dependency confusion, typosquatting, malicious packages, compromised maintainer accounts, and attacks on transitive dependencies.

Shai-Hulud illustrated how quickly these risks can combine. First observed in September 2025, the npm malware harvested secrets and used stolen npm tokens to publish malicious versions of other packages accessible to compromised maintainers. After compromising one maintainer, the malware could use that maintainer’s npm tokens to infect other packages they were authorized to publish, allowing the same process to repeat as more credentials were exposed. This gave the campaign worm-like, self-propagating behavior across the npm ecosystem. Invicti’s analysis of the Shai-Hulud npm worm covers the propagation mechanics and later second wave in more detail.

Dependency controls should therefore address both known vulnerabilities and trust in the package itself.

Useful practices include:

• Scan direct and transitive dependencies with SCA.
• Commit and enforce lockfiles where the package ecosystem supports them.
• Review unexpected dependency additions and major version changes.
• Define approved package registries and license policies.
• Protect private package namespaces against dependency confusion.
• Monitor dependencies for newly disclosed vulnerabilities after deployment.
• Review package provenance, maintenance activity, and ownership when adopting new components.

Exact version pinning can reduce unexpected upgrades, but it is not a substitute for vulnerability monitoring. A precisely pinned vulnerable version remains vulnerable. Teams need a controlled process for detecting, evaluating, testing, and deploying dependency updates.

Best practice 2: Maintain SBOMs and visibility into AI components

A software bill of materials is a machine-readable inventory of components associated with a software product or build. During a major vulnerability disclosure, an SBOM can help answer a basic but urgent question: “Where are we using this component?”

That makes SBOMs useful for vulnerability response, software asset visibility, customer requirements, and compliance activities.

Effective SBOM programs should:

• Generate SBOMs automatically for production builds.
• Associate each SBOM with a specific application, artifact, or release.
• Include direct and transitive dependencies where tooling allows.
• Use interoperable formats such as SPDX or CycloneDX.
• Retain SBOMs alongside relevant build and release records.
• Continuously monitor inventoried components for newly disclosed vulnerabilities.
• Make SBOM data searchable across applications and projects.
• Establish processes for consuming SBOMs supplied by vendors.

An SBOM is an inventory, not a vulnerability verdict. Teams still need vulnerability intelligence and security testing to determine what an identified component means for a specific application.

Extend component visibility to AI systems

AI-enabled applications add dependencies that a conventional software inventory may not fully describe. These can include models, datasets, AI frameworks, model-serving infrastructure, and external AI services.

Industry BOM standards are already expanding to represent these relationships. CycloneDX supports machine learning BOM information for models, datasets, frameworks, and related dependencies, while SPDX 3 includes an AI Profile for documenting and exchanging information about AI software packages, models, and datasets.

CISA’s updated SBOM guidance also identifies AI software as an area where additional SBOM elements may be warranted, although this remains an area of ongoing work rather than a finalized separate federal AI-BOM minimum-elements standard.

Organizations building or consuming AI-enabled software should consider inventorying:

• AI and machine learning models
• Model versions and providers
• Training, evaluation, or other relevant datasets where applicable
• AI frameworks and libraries
• Model-serving infrastructure
• External AI APIs and services
• Relationships between models and conventional software components

Regulatory requirements are developing alongside these technical standards. In the EU, for example, the AI Act includes documentation and transparency requirements for different classes of AI systems and models. Article 50 transparency obligations apply from August 2, 2026, while other requirements follow different timelines depending on the system and risk category. An AI component inventory can support governance without being treated as a compliance mechanism by itself.

AI component inventory also needs to be paired with application-level testing. Knowing that an application uses an LLM does not reveal whether its implementation is vulnerable to prompt injection, insecure output handling, excessive tool access, or other LLM-specific risks. These concerns are part of the broader software supply chain risks introduced by AI-driven applications, where models, SDKs, plugins, APIs, and external AI services add new dependencies and attack paths.

Best practice 3: Protect secrets and software identities

Credentials are a recurring link in software supply chain compromises because build systems and package registries depend on trusted identities.

A stolen publishing token can let an attacker release a malicious package under a legitimate name. A CI/CD credential can provide access to source code, artifacts, cloud infrastructure, or additional secrets.

The Axios compromise in March 2026 showed the impact of compromised publishing access. Attackers used a compromised maintainer account to publish malicious Axios versions 1.14.1 and 0.30.4. Those versions added plain-crypto-js@4.2.1, a malicious dependency whose post-install behavior delivered a cross-platform remote access trojan for Windows, macOS, and Linux. Microsoft attributed the campaign’s infrastructure to Sapphire Sleet, a North Korean state actor. Invicti’s analysis of the Axios npm compromise provides the incident timeline and technical details.

For a package with tens of millions of weekly downloads, even a short compromise window can create significant downstream exposure.

Supply chain identity controls should include:

• Scan source code and repository history for exposed secrets.
• Scan CI/CD configuration and relevant artifacts for credentials.
• Require multifactor authentication for privileged accounts.
• Prefer phishing-resistant authentication for sensitive administrative access.
• Replace long-lived credentials with short-lived credentials where possible.
• Use OpenID Connect (OIDC) or trusted publishing mechanisms instead of static CI/CD secrets where supported.
• Scope tokens to the minimum permissions and resources required.
• Monitor publishing and administrative activity.
• Rotate exposed credentials promptly and investigate their use.

Secrets scanning can identify exposed credentials, but it should sit inside a broader identity security program. A credential that was never committed to source can still be stolen from a developer workstation, CI runner, or compromised dependency.

Best practice 4: Harden CI/CD pipelines and pin third-party actions

CI/CD systems are unusually valuable supply chain targets because they combine trusted code execution with access to repositories, credentials, build artifacts, and deployment environments.

Third-party actions and plugins extend that trust to external code.

The March 2025 compromise of tj-actions/changed-files demonstrated one specific danger. Attackers compromised the project and repointed existing version tags to a malicious commit. Workflows using those mutable tags could then execute the compromised code, which attempted to expose CI/CD secrets through workflow logs. Invicti covered the tj-actions/changed-files supply chain attack shortly after its discovery.

Mutable tags were therefore an enabling condition that expanded the attack’s reach. They were not the initial compromise vector.

For third-party GitHub Actions, referencing a full commit SHA can reduce this particular risk:

uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683

Teams should combine immutable references with controlled dependency update tooling so pinned actions do not simply become permanently outdated.

Other CI/CD controls include:

• Use least-privilege workflow permissions.
• Restrict secrets to the jobs and environments that require them.
• Protect pipeline configuration through branch protection and code review.
• Use ephemeral build environments where practical.
• Closely control persistent self-hosted runners.
• Monitor unusual network activity from build environments.
• Protect release and artifact-signing processes.
• Require review for changes to security-sensitive workflows.
• Generate and verify provenance for build artifacts where appropriate.

Learn from the Trivy and LiteLLM cascade

The 2026 Trivy incident showed why CI/CD dependencies deserve the same scrutiny as application dependencies.

According to Aqua Security’s Trivy incident report, attackers used compromised credentials to publish malicious Trivy artifacts and force-pushed existing trivy-action and setup-trivy version tags to malicious commits. Pipelines referencing mutable tags could therefore run attacker-controlled code without changing their own workflow definitions.

The incident also illustrates how one supply chain compromise can create conditions for another. The LiteLLM incident record states that the subsequent PyPI compromise originated from the compromised Trivy security-scanning dependency. Malicious LiteLLM versions 1.82.7 and 1.82.8 were then published to steal credentials.

The broader lesson is to treat CI/CD tooling as executable third-party code with privileged access, not merely as pipeline configuration.

Best practice 5: Secure container images

Container images package application code together with dependencies, operating system components, configuration, and supporting tools. A vulnerable or malicious component in a base image can therefore propagate across every workload built from it.

Container security should include:

• Use minimal, maintained base images appropriate to the workload.
• Scan images during build and when they enter a registry.
• Scan both application and operating system components.
• Generate SBOMs for container images.
• Sign images and verify signatures before deployment where appropriate.
• Avoid running containers as root unless required.
• Remove unnecessary tools and packages.
• Monitor deployed images for newly disclosed vulnerabilities.
• Track the exact image deployed to each environment.

Container scanning should also connect back to application context. A long list of component CVEs is useful for coverage, but teams still need to understand which applications contain an affected image and what exposure that application presents.

Best practice 6: Protect package registries and verify provenance

Package registries sit at a critical trust boundary between publishers and consumers.

Attackers can target this boundary through account takeover, stolen publishing credentials, typosquatting, dependency confusion, malicious new packages, or compromised legitimate packages.

Useful registry controls include:

• Require MFA for publishing accounts.
• Prefer short-lived or workload-bound publishing credentials.
• Use trusted publishing mechanisms where supported.
• Scope internal packages to controlled namespaces.
• Configure package resolution explicitly for private packages.
• Monitor public registries for confusing or impersonating package names.
• Review unexpected new dependencies before adoption.
• Verify package provenance where the ecosystem supports it.
• Restrict who can publish organizational packages.
• Monitor changes to package ownership and publishing behavior.

Provenance can help establish where and how an artifact was built or published. It does not prove that the software itself is secure, so it should complement SCA, malware detection, code review, and application security testing.

Best practice 7: Scan infrastructure as code

Infrastructure-as-code templates define the environments where applications run. A secure application component can still be exposed through an insecure deployment configuration, while a vulnerable component can become more dangerous when combined with excessive privileges or unnecessary network exposure.

Teams should scan infrastructure definitions before deployment for issues such as:

• Overly permissive identity and access management policies
• Publicly exposed storage
• Unnecessary network access
• Exposed administrative services
• Insecure Kubernetes configurations
• Containers running with excessive privileges
• Missing encryption or logging controls
• Unsafe defaults in Terraform, CloudFormation, Helm, and related configuration

Policy-as-code controls can enforce organization-specific requirements alongside vulnerability and misconfiguration scanning.

Infrastructure security should also continue after deployment. Configuration drift can make a previously reviewed environment materially different from the IaC definition that was originally approved.

Best practice 8: Validate the running application with DAST

Pre-deployment controls answer important questions about source code, dependencies, configurations, and artifacts. They cannot provide a complete view of the assembled application that an attacker can actually reach.

Dynamic application security testing (DAST) approaches the application from the outside while it is running. That makes it useful for finding vulnerabilities and misconfigurations that depend on runtime behavior, application architecture, authentication, APIs, server configuration, or interactions between components.

This distinction matters for supply chain security.

SCA can tell you that a vulnerable component is present in the dependency tree. An SBOM can tell you which application or build contains that component. DAST can test the running application for externally exposed vulnerabilities, including weaknesses associated with vulnerable or outdated technologies where a suitable dynamic check exists.

DAST should not be described as a universal CVE exploitability oracle. Some vulnerable components or code paths cannot be exercised or identified dynamically, and some supply chain problems occur entirely in build infrastructure rather than in the deployed application.

The techniques are complementary:

• SCA provides broad component and dependency visibility.
• SBOMs provide inventory and traceability.
• SAST examines first-party source code before runtime.
• Container and IaC scanning cover deployable artifacts and infrastructure definitions.
• DAST tests the assembled web application and API attack surface at runtime.

The Invicti platform’s DAST includes checks for vulnerable and outdated technologies identified in running applications, complementing the static dependency visibility that SCA provides. For vulnerability classes where safe automatic exploitation is possible, Invicti’s proof-based scanning can also provide evidence that a reported application vulnerability is exploitable, helping reduce manual verification work.

Modern applications also expose much of their functionality through APIs, so runtime coverage needs to extend beyond browser-facing pages. Invicti’s API security testing combines API discovery with dynamic testing to identify and test documented and undocumented endpoints.

Best practice 9: Extend supply chain security to vendors

Your software supply chain includes software that your organization buys and integrates as well as software it builds.

A vendor can introduce risk through vulnerable software, insecure update mechanisms, compromised credentials, excessive API permissions, or weak incident response processes.

Vendor assessments should be risk-based. A SaaS provider handling public marketing content does not require the same scrutiny as a vendor whose software runs inside production infrastructure or has access to customer data.

For higher-risk vendors, consider asking:

• Do you maintain SBOMs for production software?
• Can you provide SBOM data in SPDX or CycloneDX?
• How do you identify vulnerable direct and transitive dependencies?
• How are package and release publishing identities protected?
• Do you use artifact signing or provenance?
• How do you secure your CI/CD environment?
• What application security testing do you perform before and after deployment?
• Do you maintain a vulnerability disclosure process?
• How quickly do you address critical vulnerabilities?
• How will customers be notified of a supply chain compromise?

Contractual requirements can also define SBOM delivery, vulnerability notification, remediation expectations, and security incident reporting where justified by the vendor’s risk.

Master software supply chain security checklist

Use this checklist as a starting point and adapt it to your development stack, deployment model, and risk profile.

Dependencies

• Scan direct and transitive dependencies.
• Use lockfiles and integrity controls where supported.
• Review unexpected dependency changes.
• Define approved registries and package policies.
• Monitor deployed dependencies for new vulnerabilities.

SBOMs and AI components

• Generate SBOMs for production builds and key artifacts.
• Link SBOMs to exact application and release versions.
• Support interoperable formats such as SPDX or CycloneDX.
• Keep component inventory searchable and continuously monitored.
• Inventory relevant AI models, datasets, frameworks, and services for AI-enabled applications.

Secrets and identities

• Scan code, history, and CI/CD configuration for secrets.
• Require strong MFA for privileged accounts.
• Prefer short-lived credentials and trusted publishing.
• Apply least privilege to tokens and service identities.
• Monitor and promptly rotate exposed credentials.

CI/CD

• Pin third-party actions to immutable references where practical.
• Minimize workflow permissions.
• Protect pipeline configuration changes.
• Restrict access to CI/CD secrets.
• Monitor build environments and protect artifact publication.

Containers

• Use maintained, minimal base images.
• Scan images before deployment.
• Generate container SBOMs.
• Sign and verify artifacts where appropriate.
• Monitor deployed images for new vulnerabilities.

Package registries and provenance

• Restrict package publishing permissions.
• Protect internal package namespaces.
• Use trusted publishing where supported.
• Verify provenance for critical packages and artifacts.
• Monitor for typosquatting and suspicious publishing activity.

Infrastructure as code

• Scan IaC before deployment.
• Enforce high-value controls with policy as code.
• Review excessive identity and network permissions.
• Protect infrastructure policy exceptions.
• Monitor production environments for configuration drift.

Runtime testing

• Run authenticated DAST against representative deployed environments.
• Include APIs and authenticated application areas in testing.
• Retest after significant application or dependency changes.
• Correlate runtime findings with other AppSec signals where possible.
• Retest reported vulnerabilities after remediation.

Vendors

• Apply risk-based security requirements to critical vendors.
• Request SBOMs where they support a concrete security or compliance need.
• Review vendor build, publishing, and application security practices.
• Define vulnerability and incident notification expectations.
• Monitor vendor advisories and material security changes.

How the Invicti platform supports software supply chain security

Software supply chain controls generate security signals at many different stages. The operational challenge is turning those signals into a coherent view of application risk.

Invicti AppSec Core brings essential application security capabilities into the Invicti Application Security Platform, including SAST, SCA, SBOM, container security, secrets detection, IaC scanning, API security, DAST, and ASPM. Rather than treating these as unrelated products, the platform provides centralized visibility and correlation across findings from code to cloud to runtime.

For supply chain security, that supports several complementary layers.

SCA identifies vulnerable components in application code, while SBOM capabilities help teams inventory components and map them to applications. Container and IaC scanning extend visibility into deployable artifacts and cloud application configurations. Secrets detection identifies exposed credentials in source and configuration data.

DAST adds the runtime perspective. Invicti dynamically tests running web applications and APIs, including security checks for vulnerable and outdated technologies. For many common application vulnerabilities, proof-based scanning can automatically provide evidence of exploitability rather than leaving teams to manually validate every reported issue.

Application security posture management (ASPM) provides the management layer across these signals, collecting, correlating, and prioritizing findings to provide a clearer view of application risk. Invicti’s SBOM management capabilities can also maintain component inventory across applications and help teams identify affected projects when new component vulnerabilities emerge.

This is especially important because supply chain security cannot be reduced to a single scanner. Component inventory, code analysis, infrastructure controls, and runtime testing each expose different parts of the problem.

The practical goal is to know what is in an application, protect how it is built and deployed, test what is actually running, and use all of that context to prioritize remediation.

Build supply chain security around layers of evidence

No single control can secure the entire software supply chain.

SCA can identify vulnerable dependencies. SBOMs provide component inventory. Identity and CI/CD controls protect trusted build processes. Provenance helps establish where artifacts came from. Container and IaC scanning extend security checks into deployment. Vendor governance addresses dependencies outside your direct control.

DAST adds another necessary layer by testing the assembled application and API attack surface at runtime.

Bringing those signals together gives AppSec teams a more useful model of supply chain risk: know what you use, control how software is built, protect what you deploy, test what is running, and prioritize remediation using evidence from across the application lifecycle.

If you want to see how those layers work together in practice, request an Invicti demo to see how the platform combines software composition analysis, application and API testing, runtime validation, and centralized risk management in one AppSec workflow.