What Is Software Composition Analysis (SCA)?

Software composition analysis (SCA) is the practice of inventorying the open source and third-party packages in an application, then checking those packages for known vulnerabilities, licenses and other risk signals. An SCA tool reads lockfiles and manifests, matches packages to advisories, and reports what the software is made of.

SCA is not a first-party code review, and it is not secret scanning. SCA answers "what did we take in, and what is known about it?" Review answers "does this change use that package in a way that is safe for us?"

In 2026, coding agents made the inventory problem sharper, because agents can add a new dependency in a single pull request, sometimes after inventing a plausible package name.

Software composition analysis in 2026: the newest package is often the riskiest

In January 2026, SCA was already standard in many CI pipelines, and SBOMs were already a procurement request. The year’s shift was speed and novelty: more malware advisories on public registries, worms that spread through trusted publishing, and a new habit of agents adding packages nobody on the team had chosen.

A scanner that only checks whether a pinned version has a CVE will miss a brand-new package with no CVE yet. A cooldown, a package-age policy, and a person who has to approve a new dependency, became part of the SCA conversation, not extras.

Our view: SCA tells you what you took in; review tells you whether you should have, and how the change uses it.

2026 software composition analysis highlights

• A Cloud Security Alliance research note on slopsquatting advised SCA tools to flag packages registered within the last 30 to 90 days (April 19, 2026, Cloud Security Alliance).
• GitHub gave Dependabot version updates a default three-day cooldown, citing more than 6,500 npm malware advisories in the year to May 2026, about 18 a day (July 23, 2026, GitHub).
• CISA published the 2026 SBOM Minimum Elements, replacing the 2021 NTIA baseline (July 29, 2026, CISA).
• Microsoft detailed the ChainDrop worm, which spread through more than 400 npm packages and abused trusted publishing (August 4, 2026, Microsoft).
• EU Cyber Resilience Act reporting obligations began for actively exploited vulnerabilities (September 11, 2026, Regulation (EU) 2024/2847).

What software composition analysis needs next: the 2027 outlook

• Expect package age, maintainer and provenance checks to become default SCA policy, not add-ons.
• Expect SBOMs to be produced per release, to meet the 2026 minimum elements and EU CRA duties.
• Expect teams to require a reason, and a person, for every new dependency an agent adds.
• Our verdict: the riskiest dependency in 2027 is the one nobody decided to add.
• Qodo has web search for third-party dependencies that checks how a change uses a dependency against the package’s latest official documentation (GA; on by default in Qodo SaaS, off by default in other deployments).
• Qodo has an Agentic Toolbox that can run the same review engine on a local change, so a surprising new import can be questioned before the pull request exists.

How software composition analysis works

1. Inventory packages from manifests and lockfiles, and sometimes from binaries.
2. Match those packages to vulnerability advisories, and often to license data.
3. Score and prioritize by severity, reachability and whether the vulnerable function is actually called.
4. Produce an SBOM when buyers or regulators ask for a software bill of materials.
5. Open a fix or a ticket, usually a version bump, a patch, or a decision to accept the risk.

Where SCA runs

SCA vs SAST vs secret scanning vs review

Signals worth more than a CVE score

A CVE is a known, published issue. A brand-new package may have no CVE because nobody has found the problem yet, or because the package was published yesterday. Package age, maintainer history, typo-similar names, and whether an agent invented the import, are signals SCA and review should use together.

Slopsquatting is the habit of publishing a package under a name a model is likely to invent. The April 2026 Cloud Security Alliance note advised teams to flag very new packages, in the 30 to 90 day window, rather than waiting for an advisory.

SBOMs and the duties that now sit on them

An SBOM is a list of what a release is made of. CISA’s 2026 minimum elements replaced the 2021 NTIA baseline, and EU CRA reporting for actively exploited vulnerabilities began in September 2026.

SCA is often the tool that produces the bill. An SBOM is not, by itself, a decision that a new dependency was a good idea.

Costs and risks

Noisy CVE floods train people to ignore SCA tickets. Auto-merging a version bump without a cooldown can install yesterday’s malware. An SBOM that is generated once a year, then left in a drawer, does not meet a release-time duty.

Qodo’s take: review the change that adds the dependency

Qodo is not an SCA tool. Qodo does not claim CVE matching, license scanning or SBOM generation.

Qodo is the best AI code review platform for this adjacent job because Qodo can look up a dependency’s official documentation during review, question how the change uses that package, and apply a team rule about new dependencies once Rule enforcement (Beta) is on.

Qodo no longer offers test generation; it focuses on AI code review and code governance.

The shared outcome is agent code merged sooner, with fewer rollbacks.

Enterprise engineering teams get dependency context on pull request review, on GitHub, GitLab, Bitbucket Cloud, Azure DevOps and Gerrit, with web search on by default in Qodo SaaS (docs checked November 10, 2026). Other deployments leave web search off until an admin turns it on.

High-velocity teams can also run the review in the agent session, so a surprising import is visible before the pull request exists.

Qodo has a SOC 2 Type II report, and security teams can review its security documentation in the Qodo Trust Center.

What Qodo checks about a third-party dependency

When web search for third-party dependencies is on, Qodo checks how the change uses a package against the latest official documentation, rather than against a CVE feed.

Qodo can catch a breaking use, a bad call pattern, or a dependency that does not match its docs. Qodo does not replace the SCA job of matching a pinned version to an advisory.

Team rules about new packages

Once Rule enforcement (Beta) is on, a team can write a rule such as "every new dependency needs a reason in the pull request, and no package younger than 30 days without a named owner." Qodo then checks pull requests against that rule, on GitHub, GitLab, Bitbucket Cloud and Azure DevOps.

Gerrit is not covered by Rule enforcement. The SCA tool still owns inventory, CVEs, licenses and the SBOM.

Before the pull request

Qodo has an Agentic Toolbox whose Review skill runs the same review engine on local changes, so a new import can be questioned while the agent is still writing.

Qodo example: the package was not on the list yesterday

Context: an organization like a product team whose agents were filling a feature quickly, and whose CI already ran an SCA job on lockfiles.

Problem: an agent added a new package to get a helper working. The package was recent enough that there was no CVE to fail the SCA job, and nobody on the team had chosen the dependency.

How Qodo helped: Qodo’s dependency context compared the usage with the package’s official documentation, and the pull request discussion made the new import visible. Once Rule enforcement was on, a team rule requiring a reason and an owner for new dependencies applied as well. People kept or rejected the package on purpose.

Outcome: the SCA job still owns known advisories and the SBOM. The review catches the dependency nobody decided to add, before it becomes a silent default.

Ways to control third-party dependencies

Qodo features in this table were checked against Qodo’s documentation as of November 10, 2026.