SCA explained simply

The internet is everywhere in our lives now. So are apps: to order food, file your taxes, talk to your family.
Some of them are not exactly well secured… and one fine morning, an email lands telling us our data has leaked.

SCA (Software Composition Analysis) inventories the components reused by software and looks for their known vulnerabilities. This article explains how those components get into an application, then how to check and handle an alert.

Software is a sequence of instructions a computer runs to provide a service: show a page, record an order, send a message. Part of those instructions, the code, is written by the team building the software.

But in IT, engineers are ingenious (or lazy, take your pick): the goal is not to reinvent the wheel.

And that works out nicely, because librarieslibraries: pieces of software written by others, reused instead of rewritten, bits of code other developers have already written and that we can plug into ours, fit that need perfectly.

Only… when you import a library, you also import its flawsflaws: a mistake in software that an attacker can use to make it do what it should not.

SCA helps find these flaws in what we import. It also tracks licenses, but here we focus on vulnerabilities.

Tip: words with a dotted underline have a definition. Hover over them, or tap them on a phone.

The tip of the iceberg

When we think of an application, we think of the code the team wrote: the screens, the buttons, the business rules. That is the tip of the iceberg.

Below the waterline sits everything we imported. And that is the big chunk.

Every year, the vendor Black Duck combs through the code of hundreds of commercial applications (965 in its 2025 report). The result: 97% of them contain open-source codeopen-source code: code published freely, that anyone can read, use and change, and on average 70% of their code is open source brought in from outside.

The applications audited ship 911 open-source components on average. The 2026 edition confirms it: 98%, and 1,180 components on average.

Watching our own code covers only part of the iceberg.
And as the Titanic learned, it is not the visible part that sinks the ship.

The cake and the ingredient list

Picture a bakery that makes fifty different cakes. One day, the flour supplier announces that a batch is contaminated. Two ways to react:

An application works the same way.
The flour is a library.

The ingredient list is called a software composition list (specialists say SBOMSBOM: Software Bill of Materials: the developer's shopping list, with every block and its version, for Software Bill of Materials). It also records versions, the equivalent of batch numbers.

Think of it as the developer's shopping list: everything that went into the basket, with brand and batch. Without one, every alert turns into a treasure hunt.

Russian dolls in the cake

Back to the kitchen. The bakery does not make everything itself: it buys a chocolate spread, biscuits, an icing. The biscuit contains chocolate chips. The chips contain an emulsifier, soy lecithin (E322). And so on.

It is a matryoshka: you open one doll, there is a smaller one inside, then another, then another. Software is built the same way:

• The home-made touch: our code.
• The preparations we chose: the libraries the team added itself, called direct dependenciesdirect dependencies: the libraries the team chose and declared itself.
• Everything they brought along, doll after doll: transitive dependenciestransitive dependencies: the libraries that come with the ones the team chose.

The smallest doll, the one at the very bottom, nobody really chose.
It came along with the rest. According to the 2025 report, almost two components in three (64%) arrive this way, without the team asking for them.

And attackers have understood that very well.

When the attack comes in through the back door

In recent years, several striking attacks came in where nobody was looking, at the bottom of the matryoshka. There are two families: the accidental flaw, a mistake in an honest block, and the block booby-trapped on purpose.

1. 2021
   Log4Shell: the flaw in the logbook.

   Log4j is a block that keeps an application's loglog: the notebook where a program writes down everything that happens: who logged in, which error occurred. In December 2021, it turned out that on a vulnerable application, a simple booby-trapped text, typed into a form or a game chat, could be enough to make it run an attacker's program.

   Severity score: 10 out of 10. Even Minecraft was affected.

   And many affected teams had never chosen Log4j: it had arrived, at the bottom of the label, with another block.

2. 2024
   xz: the doll nobody had ever opened.

   xz is a small compression tool found in many LinuxLinux: a free operating system, running on most servers versions.

   Its maintainermaintainer: the person who looks after an open-source project: they review proposals, decide what goes into the code and publish new versions, the one who accepts changes and publishes versions, was a single, overloaded volunteer, Lasse Collin.

   A contributor, Jia Tan, earns his trust with solid fixes, while unknown accounts push him to hand over. Jia Tan becomes a maintainer in turn, then in 2024 slips a backdoorbackdoor: a secret way in hidden inside software, which lets in whoever planted it into two versions, hidden outside the code others reviewed.

   Who was behind the Jia Tan alias? Still unknown.

   And xz serves many standard Linux tools, including some that manage servers remotely: trapping it meant aiming at a large part of the internet in one go. An engineer, Andres Freund, puzzled by oddly slow logins (about half a second too slow), pulled the thread and revealed the backdoor on 29 March 2024, before it reached the stable releases of the major distributions.

   Half a second of lag: that is what the discovery hung on.

3. 2025
   chalk and debug: two hours, two billion.

   On 8 September 2025, the maintainer of several very popular JavaScriptJavaScript: the language of web pages, also widely used on servers blocks received a fake email asking him to reset his two-factor authenticationtwo-factor authentication: a second check on top of the password, for example a code sent to your phone. He fell for it.

   The attackers immediately published booby-trapped versions of 18 libraries, including chalk (which adds colour to messages) and debug, libraries normally downloaded more than 2 billion times a week between them. The added code tried to hijack cryptocurrency payments in visitors' browsers.

   The trick was spotted and the bad versions pulled in about two hours. But chalk very often arrives indirectly, as a stowaway in the luggage of hundreds of other tools.

   And if a trapped version ran on your machines, also look for what it may have done.

4. 2026
   OpenAI: one image, three dolls.

   On 25 July 2026, researchers from the company Hacktron uploaded a specially crafted image to OpenAI's forum. The forum runs on Discourse, which hands HEIC images to ImageMagick, which hands them in turn to a small library, libheif.

   That last one, three floors down, held the flaw. Combined with a faulty login setting, it let them, according to Hacktron, demonstrate sensitive access without reading internal code.

   Luckily, they were researchers: they reported it through OpenAI's bug bounty programmebug bounty programme: a company pays researchers who report a flaw to it, and OpenAI confirmed its fix about 14 hours later.

What they have in common:each time, many victims had never chosen the faulty block.
It came in off the cushion, like a bank shot in pool.

And there is worse than an honest block trapped from the inside: a block that is malicious from the start. Attackers publish blocks with a name almost identical to a famous one, betting on a typo, or with a name an AI assistant sometimes makes up (a study of 16 models found more than 200,000).

A tool that compares against known flaws does not always catch them: checking what you install remains essential.

OK, so what does an SCA tool actually do?

Think of a product recall service, but for software blocks. It does four things:

• It takes inventory.It unpacks every box it can read, down to the bottom, and records each block with its version number.
• It checks public alerts.Most known flaws get a number, a CVECVE: Common Vulnerabilities and Exposures: a unique number, such as CVE-2021-44228, for a public flaw, and booby-trapped blocks are flagged in security advisory databasessecurity advisory databases: public lists of alerts issued when a flaw is found, with the affected versions and how to fix them. The tool looks your blocks up in them.
• It sorts.Three hundred alerts cannot all be handled at once. It helps choose where to start.
• It keeps watch.A block that is fine today can be flagged tomorrow. So the check runs continuously, not once a year.

And what it cannot do: guess an attack nobody has discovered yet. A tool that only relies on public alerts sees a booby-trapped block once it is listed there: for chalk, specialised tools spotted it within minutes, public databases a little later.

An SCA shortens the time between the alert and the reaction; it does not read the future.

Fixing means updating… then putting it into service

The fix is almost always a new version of the block, published by its authors. It takes four steps:

1. Day 0

   The flaw is announced, usually with a fixed version.

2. Step 1

   The team updates the block in its project, or the one that brings it in.

3. Step 2

   We check everything still works (an update can break something else, otherwise it would be too easy).

4. Step 3

   We put the new version into service. Until then, the site your visitors see still runs the old block.

Key point:"fixed in the project" does not mean "fixed for users". When someone tells you it is fixed, ask when it went into service.

Not all alerts are equal

Back to the kitchen one last time. A soda with vitamin C (E300) and benzoate (E211) can form benzene, mostly when it heats up in the sun; having both in the bottle is not enough. Flaws are the same: the list says what is present, not what reacts in your case.

Log4Shell, for example, only fired if the application wrote a text from outside into its log. A team that had checked nothing like that reached Log4j had the block, but not the dangerous mixture. It still had to update, just with less urgency.

That is where the real work is. The inventory, a tool does quickly.
Knowing which of those alerts really react in your case is another story. Four questions help sort them:

And when the tool gets it wrong

Like any detection tool, an SCA can be wrong both ways:

But "we do not use it" is an assessment, not a certainty: write it down, date it, and update anyway as soon as you can. A team drowning in alerts ends up not reading them, and that is when the real one slips through the net.

Where do these alerts that do not concern you come from? The wrong block, the right block but harmless for you, or a doubt to clear. Most often, from here:

• The right name, but an unknown version.The tool finds the block but not its exact version, for example because the project has no lockfilelockfile: a file that pins the exact version of every installed block or only declares a range such as “2.x”. When in doubt, it alerts.
• A namesake.Two blocks share the same name, and the tool mixes yours up with the one that has the flaw.
• Already fixed quietly.Some Linux distributions fix a flaw while keeping the original version number (only a package suffix changes): on paper the version looks vulnerable, in reality it no longer is.
• The faulty part is not used.The block is there, but no call to the affected function was found within the verified scope.

What SCA does not cover on its own

SCA looks at the blocks we reuse, the part of the iceberg under water. For the rest, you need other tools:

Your turn: chef in a crisis

You now hold all the cards: into the kitchen. You run the bakery for five days, and every morning a recall notice lands. Your shopping list (the SBOM) shows what matches. You decide what to do: each choice protects your customers… or fills the bin.

The moral of the story: finding the ingredient, the list does on its own.
Deciding what to do with it is where everything else happens.

Quick quiz

Common questions

Wrapping up

An application is largely made of building blocks written by others, and their flaws become yours. An SCA tool keeps the list of those blocks and warns you when one of them is flagged; the real work starts after that: checking whether the flaw affects you, updating, then putting the new version into service. Keep the three opening questions in mind: the complete list, the reaction time, and the proof that the flaw does or does not concern you.

Words from this article · 8 words

SCA

Software Composition Analysis: analysis of the blocks an application reuses, to find known flaws.

Library

A piece of software written by others, which you reuse.

Direct dependency

A block chosen and declared by the team.

Software bill of materials (SBOM)

The ingredient list of a piece of software, short for Software Bill of Materials.

CVE

A unique public identifier given to a known flaw.

Dependency

A block your application needs.

Transitive

A synonym for "indirect", the dependency of a dependency.

Lockfile

A document that pins the exact versions in use, so everyone installs the same thing.

To go further: to see what each level of analysis gives on the same application, and where those analyses reach their limits, read the deep dive.

Read next: SCA: from inventory to priority