DEV Community: Vulert

The TanStack Supply Chain Attack — What Happened and What It Means for npm Security

Vulert — Mon, 03 Aug 2026 07:40:00 +0000

The tanstack supply chain attack in May 2026 showed how quickly a trusted JavaScript package ecosystem can become a delivery path for credential-stealing malware when the attacker reaches the publish process.

Security researchers reported that TanStack npm packages were compromised as part of the broader Mini Shai-Hulud campaign. This guide explains what happened, why TanStack was a high-value target, how teams can check whether they were affected, and why CVE-based scanning is necessary but not enough for this class of npm supply chain attack.

Warning: This attack was not a normal vulnerable-package CVE event. Legitimate packages were modified with malicious behaviour, so response requires version checks, secret rotation, CI/CD review, and continuous monitoring.

What Happened in May 2026

On May 11, 2026, Socket reported a compromise across 84 npm package artifacts in the @tanstack namespace. The affected packages were modified with suspected CI credential-stealing malware. TanStack packages are widely used in JavaScript and React applications, which made the compromise important even before the broader campaign expansion became clear.

The attack was part of a wider campaign known as Mini Shai-Hulud. Akamai later reported that the May 11 wave hit npm packages across the TanStack dependency tree and then expanded to other projects and ecosystems, including packages linked to Mistral AI, UiPath, OpenSearch, and others. NHS England also warned that Mini Shai-Hulud affected well-known projects across npm and PyPI, including TanStack, Mistral AI, UiPath, and OpenSearch.

The exact impact for any engineering team depends on whether the team installed a compromised package version during the malicious publication window and whether the package ran in a developer workstation, CI environment, or production build path. OpenAI publicly confirmed that two employee devices were affected through the TanStack npm supply chain attack, but stated that no user data, production systems, or intellectual property were compromised.

The attack represents an evolution from single-package compromise to self-spreading supply chain infection — without manual attacker intervention.

The Mini Shai-Hulud Self-Spreading Technique

Mini Shai-Hulud is the name researchers used for a self-spreading supply chain campaign that targets package publishing environments, developer systems, and CI/CD credentials. The important shift is automation. Instead of compromising one package and waiting for users to install it, the malware attempts to reach additional package publishing paths and spread through packages the compromised identity can publish.

Public reporting describes the campaign as credential-focused. The malware attempted to find secrets, tokens, registry credentials, CI/CD credentials, and cloud credentials. In a package publishing environment, those credentials are especially dangerous because they can allow attackers to publish malicious versions of additional packages. Each new compromised package can then become another route to more developer machines and build environments.

For npm teams, this matters because package installation is not passive. npm packages can include lifecycle scripts that execute during install or build steps. If malicious code runs inside CI, it may access environment variables, npm tokens, GitHub tokens, cloud credentials, package registry credentials, deployment secrets, and other sensitive values. That makes the CI environment a primary target.

Attack Stage	What Happens	Why It Matters
Package compromise	A legitimate package artifact receives malicious code.	Developers trust the package name because it is already popular.
Credential access	The malware attempts to read CI/CD, registry, GitHub, and cloud secrets.	Secrets can allow lateral movement beyond the original package.
Publishing abuse	Compromised publishing access can be used to publish malicious versions of other packages.	The attack can expand without manual attacker work for each package.
Downstream installation	Teams that install malicious versions may expose developer or CI credentials.	The blast radius can include applications, repositories, and deployment workflows.

Why TanStack Was a High-Value Target

TanStack is a widely used JavaScript library ecosystem that includes projects such as TanStack Query, TanStack Router, and TanStack Table. These libraries are common in React and modern frontend applications. TanStack Query, previously known as React Query, is especially popular for data fetching and state management in web applications.

That popularity makes TanStack a high-value supply chain target. Attackers prefer packages that sit high in the dependency graph because one compromise can reach many downstream projects. A malicious version of a rarely used package may affect a handful of teams. A malicious version of a popular frontend library can reach developer workstations, CI environments, and build systems across many organisations.

TanStack packages are also attractive because they appear in normal application dependency files such as package.json, package-lock.json, yarn.lock, and pnpm-lock.yaml. Many teams may not install them directly every day, but automated dependency updates, lock file changes, local installs, and CI builds can still pull compromised versions if version ranges allow it.

Note: Popular open source packages are not dangerous because they are popular. They are high-impact targets because a single malicious version can reach many teams quickly.

How to Check if Your Application Was Affected

The first step is to check whether your application uses TanStack packages and whether your lock file contains versions published during the attack window. Public affected-package lists changed as researchers investigated the campaign, so teams should compare their installed package versions against the latest trusted advisory data from TanStack, Socket, npm, and their security vendors.

Do not check only package.json. It may contain broad version ranges such as ^1.2.3, while the exact installed version is recorded in package-lock.json, yarn.lock, or pnpm-lock.yaml. The lock file is the source of truth for what your build actually installed.

Search for packages in the @tanstack namespace and any other packages listed in advisories connected to Mini Shai-Hulud. If you find affected versions, treat the environment where they ran as potentially exposed. That includes developer machines, CI runners, build agents, and any environment where install scripts or malicious package code may have executed.

# Search direct dependencies in package.json
cat package.json | grep -i "@tanstack"

# Search exact installed TanStack versions in npm lock file
grep -i "@tanstack" package-lock.json

# Search Yarn lock file
grep -i "@tanstack" yarn.lock

# Search pnpm lock file
grep -i "@tanstack" pnpm-lock.yaml

# List installed TanStack packages in the current project
npm ls | grep "@tanstack"

# Search all repos from a parent directory
grep -RIn "@tanstack" ./ --include="package.json" --include="package-lock.json" --include="yarn.lock" --include="pnpm-lock.yaml"

Tip: Keep a copy of the lock file from the affected period. It helps incident responders prove which exact package versions were installed.

What to Do If You Were Affected — Incident Response Steps

If your project installed a compromised TanStack or Mini Shai-Hulud-related package version, treat it as a supply chain incident. The main concern is credential exposure. Malicious packages often target secrets because secrets allow the attacker to move from package installation into repositories, CI/CD systems, cloud accounts, package registries, and deployment workflows.

Start by identifying where the package ran. A local developer install has different exposure than a GitHub Actions workflow with publish permissions. A CI runner with cloud deployment credentials is higher risk than a read-only build. The response should be proportional to the secrets available in that environment, but teams should avoid assuming that “it only ran during install” means no damage occurred.

Check package usage: Search package.json, package-lock.json, yarn.lock, and pnpm-lock.yaml for affected packages and exact versions.
Identify execution environments: Determine whether the compromised package ran on developer machines, CI runners, release pipelines, or production build systems.
Rotate exposed secrets: Rotate npm tokens, GitHub tokens, CI/CD secrets, cloud credentials, deployment keys, SSH keys, and any credentials available to the affected environment.
Upgrade to confirmed clean versions: Move affected packages to versions confirmed clean by maintainers or trusted security advisories.
Audit CI/CD activity: Review workflow logs, package publish history, repository access logs, secret access, unusual network activity, and unexpected package releases.
Monitor after containment: Watch for suspicious pushes, new packages, new tokens, unexplained workflow runs, and unexpected changes to lock files.

# Example: force a fresh lockfile review after upgrading packages
npm install

# Prefer deterministic installs in CI after lockfile is reviewed
npm ci

# Check for unexpected dependency changes
git diff package.json package-lock.json

# Review npm account tokens manually in npm settings
# Rotate tokens that were available to any affected environment

Why CVE Databases Did Not Catch This Attack

A CVE database is built to track known vulnerabilities in software components. That is essential for issues such as CVE-2021-44228 in Log4j or other public package vulnerabilities with assigned identifiers, affected versions, and fix guidance. But the TanStack incident was different. During the attack window, the core problem was not that a known vulnerable version existed in a database. The problem was that legitimate package versions were modified with malicious behaviour.

This is why CVE-based scanning did not provide the first line of detection. Security researchers and behavioural analysis tools flagged suspicious package activity, credential-stealing behaviour, and unexpected malicious code. Socket reported that its AI Scanner flagged newly malicious TanStack packages quickly after publication, which shows the value of behavioural package analysis for unknown malware patterns.

That does not make CVE monitoring irrelevant. CVE monitoring is still necessary because most dependency security work involves known vulnerabilities, fixed versions, and ongoing alerts when new CVEs affect existing packages. But CVE scanning is one layer. Behavioural analysis, lock file pinning, registry controls, trusted publishing review, secret scoping, and CI hardening are additional layers.

Warning: Do not expect CVE scanning alone to detect brand-new malicious package versions. Pair CVE monitoring with behavioural analysis and CI/CD secret controls.

What This Attack Changes About Dependency Security Strategy

The tanstack supply chain attack changes dependency security strategy because it shows that trusted packages can become malicious without becoming “unknown packages.” A policy that only blocks unpopular packages, typosquats, or known CVEs will miss a trusted package that has been compromised at publish time.

Teams should move toward layered dependency security. First, pin versions and commit lock files so a new malicious version does not install automatically. Second, monitor lock file changes in pull requests. Third, use behavioural analysis tools that inspect package scripts, network calls, credential access, and suspicious code. Fourth, scope CI/CD credentials so a compromised package cannot access more than the build actually needs.

Fifth, keep CVE monitoring in place for known vulnerability risk. Vulert, Snyk, and similar tools help identify known CVEs in manifest files and SBOMs. Socket and similar behavioural tools help identify suspicious package behaviour. These categories are complementary, not interchangeable.

Security Layer	What It Catches	What It Misses
CVE monitoring	Known vulnerable packages with published advisories and affected versions.	Brand-new malicious package versions with no CVE yet.
Behavioural package analysis	Suspicious install scripts, credential access, exfiltration, and malware-like behaviour.	Some legitimate but vulnerable packages with no suspicious behaviour.
Lock file pinning	Unexpected upgrades to newly published malicious versions.	Compromise already present in the pinned version.
CI/CD secret scoping	Limits damage if malicious package code runs during install or build.	Does not prevent package compromise itself.
SBOM inventory	Helps identify where affected packages exist across products.	Does not detect malicious behaviour by itself.

How Vulert Fits This Kind of npm Security Programme

Vulert is a software composition analysis tool focused on known CVEs in open source dependencies. It analyzes manifest files and SBOMs against 458,000+ known CVEs, alerts teams when new CVEs affect specific packages, and provides exact fixed versions plus CLI commands. That is the known-vulnerability layer of dependency security.

For the TanStack-style event, Vulert should be used honestly as one layer, not the only layer. It helps teams know what packages they run, scan package-lock.json, yarn.lock, pnpm-lock.yaml, and SBOM files, and continuously monitor for CVEs. It does not replace behavioural malware detection for brand-new malicious package versions.

The practical strategy is to combine Vulert with lock file review, behavioural analysis, CI/CD secret hardening, and package publishing controls. Vulert helps answer “which known CVEs affect our dependencies?” Behavioural tools help answer “does this package act maliciously?” CI hardening limits damage if a malicious package runs. Together, the layers reduce both known vulnerability risk and active supply chain compromise risk.

Key Takeaways

The tanstack supply chain attack was part of the broader Mini Shai-Hulud campaign targeting npm package publishing and developer environments.
Socket reported 84 compromised TanStack npm package artifacts, and the broader campaign later affected additional projects and ecosystems.
Mini Shai-Hulud represented a self-spreading supply chain technique focused on credential theft and package publishing expansion.
Teams should check exact installed versions in lock files, not only broad dependency ranges in package.json.
If affected versions ran in CI or developer environments, teams should rotate exposed secrets and audit CI/CD activity.
CVE monitoring is necessary for known vulnerabilities, but behavioural analysis and CI/CD hardening are required for malicious package compromise.

Frequently Asked Questions

1. What was the TanStack supply chain attack?

The TanStack supply chain attack was a May 2026 npm package compromise connected to the broader Mini Shai-Hulud campaign. Security researchers reported malicious modifications to TanStack package artifacts, with behaviour focused on credential theft and supply chain propagation.

2. What is Mini Shai-Hulud?

Mini Shai-Hulud is the name researchers used for a self-spreading supply chain campaign targeting package ecosystems and developer environments. Public reporting describes it as a credential-focused attack that attempts to spread through package publishing access and CI/CD environments.

3. Does Vulert detect supply chain attacks like TanStack?

Vulert detects known CVEs in dependencies by scanning manifests and SBOMs. TanStack-style malicious package compromise may not have a CVE during the attack window, so teams should pair Vulert with behavioural package analysis, lock file pinning, CI secret scoping, and package publishing controls.

CISA’s KEV Catalog — The Most Reliable Signal for Vulnerability Prioritization

Vulert — Mon, 03 Aug 2026 07:40:00 +0000

The CISA KEV catalog should sit at the top of your vulnerability prioritization workflow because it answers the question CVSS cannot answer: is this CVE actually being exploited by attackers?

CVSS tells you theoretical severity. EPSS estimates the probability of exploitation in the next 30 days. The Known Exploited Vulnerabilities catalog documents confirmed exploitation. That difference matters when your scanner reports 300 CVEs and engineering can only patch 20 this sprint.

Note: KEV is not a replacement for CVSS, EPSS, asset exposure, or business context. It is the highest-confidence signal that attackers have already used the vulnerability in the real world.

What the CISA Known Exploited Vulnerabilities Catalog Is

The Known Exploited Vulnerabilities catalog is a public list maintained by the U.S. Cybersecurity and Infrastructure Security Agency. It contains CVEs that CISA adds based on evidence of active exploitation. That makes it different from a normal vulnerability database. A CVE can have a high CVSS score and never appear in KEV. A lower-scored CVE can appear in KEV because attackers are actually using it.

This distinction is critical for vulnerability management. CVSS measures severity in a vulnerable context. It does not prove attackers are using the vulnerability. EPSS estimates future exploitation probability using data-driven signals. That helps prioritization, but it is still predictive. KEV means exploitation has been observed or confirmed by CISA through evidence sources such as incident response, threat intelligence, and partner reporting.

For engineering teams, the rule is simple: if a CVE appears in KEV and exists in your environment, it deserves immediate attention. If it is also internet-facing, reachable, or present in a high-value application, it becomes a top-tier remediation item. This applies to infrastructure CVEs, application platform CVEs, and open source dependency CVEs discovered through SCA tools.

Unlike CVSS or EPSS, KEV is not asking whether exploitation could happen. It records that exploitation has happened.

Key Facts About the KEV Catalog in 2026

The CISA KEV catalog keeps growing because attackers continue to reuse both new and old vulnerabilities. Many organizations focus heavily on fresh CVEs, but KEV repeatedly shows that attackers exploit old flaws when systems remain unpatched. A 2017 or 2019 CVE can still be urgent if it remains exposed and appears in attacker playbooks.

BOD 22-01 requires Federal Civilian Executive Branch agencies to remediate KEV vulnerabilities by the assigned due date. CISA also urges non-federal organizations to prioritize KEV vulnerabilities as part of normal vulnerability management. That recommendation matters because KEV gives private companies a practical way to reduce noise: put confirmed exploited vulnerabilities ahead of theoretical severity-only findings.

The catalog is useful because it is machine-readable, public, and operational. Security teams can ingest the JSON feed, cross-reference it against vulnerability scan results, and label findings as KEV-listed. Engineering teams can use that label to route tickets, shorten SLAs, and explain why a medium-scored finding may outrank a higher CVSS issue.

Signal	What It Means	How to Use It
KEV	The vulnerability has confirmed exploitation evidence.	Patch first when present in your environment.
EPSS	The vulnerability has a probability estimate for exploitation in the next 30 days.	Use it to prioritize non-KEV findings with high predicted exploitation risk.
CVSS	The vulnerability has theoretical severity in a vulnerable context.	Use it as a baseline impact score, not the only priority signal.
Exposure	The affected system is reachable, internet-facing, or connected to sensitive assets.	Escalate priority when KEV or high EPSS intersects with exposure.

How to Access the KEV Catalog

CISA makes the KEV list available through the public website, a JSON feed, and a GitHub repository. The web page is useful for analysts and managers. The JSON feed is useful for automation. The GitHub repository is useful for teams that want version tracking, diffs, or scheduled ingestion into vulnerability management workflows.

For dependency scanning, automation matters. Your SCA tool may report CVEs from package-lock.json, pom.xml, requirements.txt, composer.lock, go.sum, or SBOMs. You can then cross-reference those CVEs against CISA’s JSON feed and flag any intersection. That flag becomes a ticket priority, SLA trigger, or dashboard column.

The official catalog is available at:

Web catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
JSON feed: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json

# Download the CISA KEV JSON feed
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  -o known_exploited_vulnerabilities.json

# Count KEV entries
python3 -c "
import json
data = json.load(open('known_exploited_vulnerabilities.json'))
print(len(data['vulnerabilities']))
"

# Print CVE ID, vendor/project, product, and vulnerability name
python3 -c "
import json
data = json.load(open('known_exploited_vulnerabilities.json'))
for v in data['vulnerabilities'][:10]:
    print(v['cveID'], '-', v.get('vendorProject'), '-', v.get('product'), '-', v['vulnerabilityName'])
"

Filtering KEV for Your Specific Packages

The KEV catalog is most useful when you connect it to your own environment. A raw list of exploited CVEs is helpful, but a filtered list of exploited CVEs affecting your software is actionable. For application teams, start with the packages and technologies you actually use: Apache, Microsoft, Atlassian, Jenkins, WordPress, OpenSSL, Log4j, Spring, lodash, or any other major dependency family.

Filtering by vendor or product is only a starting point. The best workflow is to compare CVE IDs from your scan results against the KEV list. That avoids false assumptions based on product names. If Vulert or another SCA tool reports a CVE in your dependency tree, the next question is whether that exact CVE appears in KEV.

# Filter KEV entries for Apache-related products
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | python3 -c "
import json, sys
data = json.load(sys.stdin)
matches = [
    v for v in data['vulnerabilities']
    if 'apache' in v.get('vendorProject','').lower()
    or 'apache' in v.get('product','').lower()
]
for v in matches:
    print(v['cveID'], '-', v['vulnerabilityName'])
"

# Example: compare your scanner CVE list against KEV
# scanner-cves.txt should contain one CVE ID per line
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | python3 -c "
import json, sys
data = json.load(sys.stdin)
kev = {v['cveID'] for v in data['vulnerabilities']}
scanner = {line.strip() for line in open('scanner-cves.txt') if line.strip()}
for cve in sorted(scanner & kev):
    print('KEV_MATCH', cve)
"

Tip: Add a kev=true label to vulnerability tickets. It gives engineering and leadership a simple reason for immediate prioritization.

The Three-Tier Prioritisation Framework Using KEV

A practical prioritization framework needs to reduce noise without ignoring risk. KEV should drive the top tier because it represents confirmed exploitation. EPSS should drive urgency for non-KEV vulnerabilities with high predicted exploitation probability. CVSS should remain the baseline severity score, but it should not be the only sorting rule.

This framework is simple enough for engineering teams to use in Jira, Linear, GitHub Issues, or a vulnerability dashboard. It also explains decisions clearly to CTOs and auditors. When a CVSS 6.5 KEV-listed CVE is patched before a CVSS 9.8 non-exposed internal issue, the reason is not arbitrary. The first one has confirmed attacker usage and reachable exposure. The second one may still be important, but it is not automatically first.

The exact response times should match your risk appetite and business context. The table below is a practical default for SaaS and engineering teams. Internet-facing KEV findings should move fastest. Non-internet-facing KEV findings still need urgent handling because exploitation evidence exists, but exposure and reachability should guide the emergency level.

Tier	Criteria	Response Time	Rationale
Tier 1 — Patch Immediately	KEV-listed CVE and present in an internet-facing, reachable, or high-value system.	Same day where possible; treat as emergency remediation.	Attackers have confirmed use of the vulnerability and your asset is exposed.
Tier 1B — Urgent KEV Remediation	KEV-listed CVE present internally but not internet-facing.	Within days, or by a documented emergency SLA.	Confirmed exploitation exists, but internal exposure may change response sequencing.
Tier 2 — Patch This Sprint	Not on KEV, but CVSS 7.0+ and EPSS above your threshold, such as 0.10.	This sprint.	The vulnerability is severe and has elevated predicted exploitation probability.
Tier 3 — Planned Remediation	Below Tier 2 thresholds, not KEV-listed, and no urgent exposure context.	Next planned remediation cycle.	The finding should be addressed systematically without disrupting emergency work.

Warning: Do not use CVSS alone as your only sorting rule. A lower-scored KEV finding can be more urgent than a higher-scored vulnerability with no exposure and no exploitation evidence.

How to Apply KEV to Your Dependency Scan Results

Your SCA tool gives you a list of CVEs in your dependencies. The CISA KEV catalog tells you which CVEs have confirmed exploitation. The operational workflow is to cross-reference both lists, then escalate any intersection. This converts a long dependency report into a prioritized remediation queue.

Start with manifest and SBOM scanning. Vulert can analyze files such as package-lock.json, yarn.lock, pnpm-lock.yaml, pom.xml, build.gradle, requirements.txt, Pipfile.lock, poetry.lock, composer.lock, go.sum, Gemfile.lock, Cargo.lock, pubspec.lock, mix.lock, *.csproj, packages.lock.json, and SBOMs in SPDX or CycloneDX format.

After scanning, sort the findings in this order: KEV match, internet exposure, EPSS score, CVSS score, package reachability, and business criticality. A KEV match in a shared authentication library should beat a high CVSS finding in a dev-only package. A KEV match in a multi-tenant SaaS dependency should trigger executive visibility because one package upgrade may reduce risk for every customer.

Scan your dependencies: Upload manifest files or SBOMs to your SCA tool and export the CVE list.
Download CISA KEV: Pull the JSON feed on a schedule and store the current CVE ID set.
Cross-reference CVEs: Mark any scanner CVE that appears in KEV as Tier 1 or Tier 1B.
Add exposure context: Escalate findings in internet-facing or customer-facing applications.
Create tickets: Include CVE ID, package name, installed version, fixed version, KEV status, owner, and due date.
Track closure evidence: Keep pull requests, tests, deployment records, and risk acceptance entries.

KEV + EPSS + CVSS — The Complete Prioritisation Picture

KEV list prioritization works best when combined with EPSS, CVSS, and exposure. Each signal answers a different question. KEV answers “has exploitation been confirmed?” EPSS answers “how likely is exploitation in the next 30 days?” CVSS answers “how severe could this be in a vulnerable context?” Exposure answers “can attackers reach our vulnerable asset?”

When signals conflict, prioritize real exploitation first. A KEV-listed CVE with a moderate CVSS score can deserve emergency remediation because attackers already use it. A high EPSS non-KEV vulnerability may deserve sprint-level urgency because exploitation probability is elevated. A high CVSS vulnerability with low EPSS, no exposure, and no KEV listing may still matter, but it may not justify interrupting the team today.

EPSS also has an important nuance: the 0.10 threshold in this guide is a practical example, not an official universal cutoff. FIRST publishes EPSS as a probability and percentile, and each organization should choose thresholds based on risk appetite, patch capacity, and exposure. The key is to define the threshold, document it, and apply it consistently.

Signal	Question Answered	Priority Weight
KEV	Has exploitation been confirmed?	Highest confidence signal.
EPSS	How likely is exploitation in the next 30 days?	Strong forward-looking signal for non-KEV findings.
CVSS	How severe could the vulnerability be?	Baseline severity signal.
Exposure	Can an attacker reach the vulnerable asset?	Escalates or de-escalates urgency based on your environment.

The Compliance Angle — What SOC2 and ISO 27001 Auditors Think of KEV

SOC2 and ISO 27001 auditors do not usually require a specific KEV workflow by name, but they care deeply about vulnerability management evidence. KEV helps show that your organization prioritizes based on real attacker activity, not only static severity numbers. That makes the process more defensible during audits, customer questionnaires, and cyber insurance renewals.

For SOC2, KEV can support evidence that the team identifies, prioritizes, and remediates vulnerabilities using risk-based criteria. For ISO 27001:2022, KEV can support Control 8.8, Management of Technical Vulnerabilities, because it helps the organization obtain timely information about vulnerabilities and assess exposure. The key is documentation: show the KEV source, how it is cross-referenced, how tickets are prioritized, and how remediation is tracked.

A good audit record includes the scan result, KEV status, exposure assessment, ticket, owner, target date, remediation action, pull request, test evidence, deployment record, and closure date. If the team cannot patch immediately, keep a formal risk acceptance record with compensating controls and a review date.

SOC2 evidence: KEV status can support risk-based vulnerability prioritization and remediation tracking.
ISO 27001 evidence: KEV cross-referencing can support technical vulnerability management under Control 8.8.
Cyber insurance evidence: KEV handling can support answers about known exploited vulnerabilities and patch timelines.
Customer questionnaire evidence: KEV-based prioritization shows enterprise buyers that active exploitation drives urgent remediation.

How Vulert Helps With KEV-Aware Dependency Remediation

Vulert focuses on open source dependency vulnerability monitoring. It analyzes manifest files and SBOMs against 458,000+ known CVEs, alerts teams when new CVEs affect specific package versions, and provides exact fixed versions plus CLI commands. That gives teams the CVE inventory needed to cross-reference against the KEV list.

The practical workflow is straightforward: upload a manifest or SBOM to Vulert, review the CVE findings, identify any KEV-listed CVEs, and prioritize those first. Vulert also provides continuous monitoring, Dependency Health grouping, Jira integration, full CVE detail, workaround guidance, vulnerability history, and trend reports. These features help teams turn vulnerability data into remediation evidence.

Vulert is not a replacement for CISA KEV, EPSS, CVSS, or asset exposure analysis. It is the SCA layer that tells you which known CVEs exist in your dependency files. Combine Vulert’s dependency findings with CISA KEV and exposure context to build a stronger prioritization workflow.

To improve your prioritization workflow, continue with this Vulert guide:

How to Build a Vulnerability Management Dashboard for Your CTO

This guide helps teams move from raw CVE lists to risk-based remediation, executive reporting, SLA tracking, and audit-ready evidence.

Key Takeaways

The CISA KEV catalog lists CVEs with confirmed exploitation evidence and should sit at the top of vulnerability prioritization workflows.
CVSS measures theoretical severity, EPSS estimates exploitation probability, and KEV records confirmed exploitation.
Federal Civilian Executive Branch agencies must remediate KEV vulnerabilities by assigned due dates under BOD 22-01, while CISA urges all organizations to prioritize KEV remediation.
Engineering teams should cross-reference SCA scan results against the KEV JSON feed and escalate any matching CVEs.
The strongest prioritization model combines KEV, EPSS, CVSS, asset exposure, reachability, and business criticality.
Vulert provides the dependency CVE inventory, scan history, fix guidance, and Jira workflow needed to support KEV-aware remediation.

Frequently Asked Questions

1. What is the CISA KEV catalog?

The CISA KEV catalog is a public list of CVEs that CISA adds based on evidence of active exploitation. KEV stands for Known Exploited Vulnerabilities. If a CVE appears in the catalog, it has confirmed exploitation evidence and should be prioritized quickly.

2. How do I check if my vulnerabilities are on the KEV list?

Export CVE IDs from your vulnerability scanner or SCA tool, download CISA’s KEV JSON feed, and compare the two CVE ID sets. Any intersection should be flagged as KEV-listed and escalated for urgent remediation.

3. Is KEV better than CVSS?

KEV and CVSS answer different questions. CVSS describes theoretical severity, while KEV confirms exploitation evidence. When the two conflict, KEV should usually drive urgent prioritization because attackers have already used the vulnerability.

Open Source Security for SaaS Companies — What Every B2B SaaS CTO Needs to Know

Vulert — Sun, 02 Aug 2026 07:00:00 +0000

SaaS open source security becomes urgent the first time an enterprise prospect asks, “How do you monitor open source components for vulnerabilities?” A weak answer can pause the deal even when the product works, the roadmap is strong, and the buyer likes the team.

B2B SaaS companies process customer data, answer enterprise security questionnaires, prepare for SOC2, face investor due diligence, and build on open source foundations. This guide explains the specific dependency security risks SaaS CTOs need to manage, how multi-tenant exposure changes prioritisation, and when continuous SCA monitoring becomes a business requirement.

Warning: When a CVE is exploited in a SaaS dependency, it is not only your data at risk. It is your customers’ data, your renewal pipeline, your procurement approvals, and your reputation.

Why B2B SaaS Companies Have a Unique Dependency Security Responsibility

B2B SaaS security requirements are different from normal internal application security because customers trust your platform with their business data. A vulnerability in your dependency tree can affect customer records, authentication flows, billing workflows, analytics pipelines, API access, and tenant isolation. That makes open source dependency security a customer trust issue, not only an engineering hygiene task.

Enterprise customers understand this. That is why security questionnaires have become standard in SaaS procurement. A 50-person SaaS company selling to Fortune 500 clients can face the same questions as a 500-person company: Do you have SOC2? Do you monitor open source dependencies? Do you maintain an SBOM? What is your critical vulnerability SLA? How do you track remediation? Can you show evidence over time?

The challenge is that SaaS teams often adopt open source faster than they build security process. A Node.js backend may depend on express, jsonwebtoken, axios, helmet, rate-limiter-flexible, stripe, and hundreds of transitive packages. A Python analytics service may rely on requests, urllib3, pandas, numpy, and machine learning libraries. Each package becomes part of the product’s risk surface.

When a CVE is exploited in a SaaS dependency, it is not your data at risk — it is your customers’ data.

The 4 Moments When Dependency Security Becomes Urgent for SaaS

Most SaaS teams do not wake up one day and decide to build a formal dependency security programme. The need usually appears during a business milestone. A major enterprise deal arrives. A Series B investor asks for technical diligence. A penetration tester asks what SCA tooling is in use. A critical CVE disclosure hits a library buried in the application.

These moments matter because they turn open source security from “good engineering practice” into a commercial requirement. The team may have shipped for years with manual checks, occasional npm audit runs, or Dependabot alerts that nobody owned. That approach can work at seed stage, but it breaks when the company sells to enterprise, handles regulated customers, or needs proof over time.

The First Enterprise Deal

The first serious enterprise deal often introduces the first serious security questionnaire. The buyer asks how the SaaS company monitors open source components for vulnerabilities. If the answer is “we check manually sometimes,” procurement slows down. If the answer includes continuous SCA monitoring, documented remediation workflow, SOC2 evidence, and scan history, the conversation is easier.

This is where SaaS open source security becomes a sales enabler. The CTO does not need to promise zero vulnerabilities. They need to show a repeatable process: dependency inventory, monitoring, alerting, triage, remediation, ticketing, and evidence.

Series B Due Diligence

Technical due diligence becomes more demanding at Series B and later. Investors, private equity teams, and acquirers may request dependency inventories, vulnerability reports, security policies, SOC2 status, SBOMs, and remediation history. An SBOM showing 200+ unpatched CVEs can become a negotiating issue. A documented vulnerability management process can become an asset.

Security diligence is not only about finding problems. It measures whether the company knows how to find, prioritise, and fix problems. That distinction matters. A company with known findings, owners, SLAs, and trend reports looks more mature than a company with unknown exposure.

The Pre-Launch Penetration Test

Penetration testing before launch or before enterprise expansion often exposes process gaps. A tester may ask which SCA tool monitors dependencies, how critical CVEs are handled, and whether dependency findings are tracked in Jira. “None” is not a strong answer once customer data and enterprise procurement are involved.

A pen test finds exploitable paths, but it is not a substitute for continuous dependency monitoring. The tester sees a point-in-time view. SCA monitoring watches package risk after the test ends, after deployment, and after new CVEs are disclosed.

The Critical CVE Disclosure

The hardest moment is the critical CVE disclosure nobody expected. A library your SaaS depends on becomes vulnerable. The first question is not “can we patch?” It is “are we affected?” Teams with continuous monitoring answer in minutes. Teams without monitoring search repositories, ask developers, inspect lock files, and lose time while customers ask for answers.

Log4Shell showed this pattern clearly. Teams that knew where log4j-core existed could respond faster. Teams without dependency visibility spent days finding exposure. SaaS companies should assume the next critical disclosure will happen and build the process before that day arrives.

SOC2 Requirements Specific to Multi-Tenant SaaS

SOC2 does not require one specific SCA vendor, but SaaS auditors care about whether controls operate over time. That is the key difference between SOC2 Type I and SOC2 Type II. A one-time clean scan is not enough for Type II evidence. The company needs records showing that vulnerability monitoring, triage, and remediation operated during the audit period.

Multi-tenant SaaS adds another concern. If a vulnerable shared library exists in the common application codebase, it can affect every tenant simultaneously. A vulnerability in authentication middleware, API rate limiting, billing integration, or data processing code can have platform-wide consequences. That makes dependency security more important than it might be for a small internal tool.

Auditors increasingly ask for evidence such as scan history, vulnerability management procedures, MTTR data, ticket records, risk acceptance entries, and remediation timelines. A SaaS company should be able to show when a CVE was detected, which application was affected, who owned remediation, what fix was applied, and when the change reached production.

Note: SOC2 evidence is about control operation over time. Keep timestamped scan history, remediation tickets, and trend reports instead of relying on screenshots taken the week before the audit.

SaaS-Specific Dependency Risks

SaaS dependency security is different because certain package categories sit on high-value paths. A vulnerability in a development-only package may matter less than a vulnerability in authentication, tenant routing, API protection, billing, or data transformation. CTOs should weigh findings by both CVSS and SaaS business context.

Authentication libraries are especially sensitive. Packages such as passport, jsonwebtoken, OAuth clients, SAML libraries, and session middleware can affect every user login. API protection libraries such as helmet, rate limiting middleware, request validation packages, and CORS utilities affect abuse prevention and exposure. Billing SDKs such as stripe and braintree sit near payment workflows, subscription state, and PCI-adjacent processes.

Data processing libraries also matter. A vulnerability in pandas, numpy, pillow, PDF parsing libraries, CSV import tools, or deserialisation packages can affect tenant data integrity or processing safety. A low-level dependency may become high priority when it processes uploaded customer data across all tenants.

Library Category	Examples	Specific SaaS Risk if Vulnerable
Authentication and session management	`passport`, `jsonwebtoken`, OAuth and SAML clients.	A vulnerability can affect login, tokens, sessions, and every tenant user.
API security and rate limiting	`helmet`, `rate-limiter-flexible`, CORS and validation middleware.	A vulnerability can expose APIs to abuse, bypass, or unsafe request handling.
Billing and payments	`stripe`, `braintree`, payment webhook libraries.	A vulnerability can affect billing events, subscription state, or PCI-adjacent flows.
Data processing	`pandas`, `numpy`, CSV, PDF, image, and document parsers.	A vulnerability can affect uploaded customer data or shared processing jobs.
HTTP clients and integrations	`axios`, `requests`, `urllib3`, API SDKs.	A vulnerability can affect outbound integrations, webhooks, and service-to-service calls.
Logging and observability	`log4j-core`, logging middleware, telemetry clients.	A vulnerability can turn normal customer-controlled input into platform-wide exposure.

The Multi-Tenant Severity Multiplier

Multi-tenant SaaS changes vulnerability prioritisation. A CVSS 6.0 vulnerability in a single-tenant internal app may be a medium-priority issue. The same vulnerability in a shared SaaS service used by 1,000 customers may deserve urgent review because the blast radius is much larger.

Traditional severity scoring does not always capture tenant impact. CVSS can describe technical impact, but it does not know whether your SaaS architecture shares code, data processing, authentication, or billing workflows across all customers. A medium vulnerability in tenant isolation, token handling, document parsing, or import pipelines can become business-critical when exploited at platform scale.

SaaS CTOs should therefore add a severity multiplier for shared code paths. If a vulnerable package sits in authentication, request routing, shared API middleware, billing, or data ingestion, increase priority. If the package is reachable from customer-controlled input, increase priority again. If every tenant uses it, escalate further.

Check reachability: Determine whether the vulnerable package runs in production and whether customer-controlled input can reach it.
Check tenant scope: Determine whether the package affects one customer environment, a subset of tenants, or the entire platform.
Check business function: Escalate vulnerabilities in authentication, billing, API security, tenant isolation, and data processing.
Check remediation path: Prioritise package upgrades that remove risk across many tenants with one change.
Document the decision: Record why the team escalated, downgraded, patched, mitigated, or accepted the finding.

Tip: Add a “tenant impact” field to vulnerability tickets. It helps engineering and leadership understand why a moderate CVSS score can still be urgent for SaaS.

Building a SaaS Security Program at Each Funding Stage

A good SaaS open source security programme should match company stage. A seed-stage team does not need the same security function as a growth-stage company selling to large enterprises. The mistake is waiting too long. By the time enterprise procurement or Series B diligence asks for evidence, the company may need months of historical records that it never collected.

At seed stage, basic controls are acceptable: Dependabot, npm audit, committed lock files, and clear ownership for dependency updates. At Series A, continuous SCA monitoring becomes more valuable because the company is preparing for SOC2 Type I, enterprise pilots, and security questionnaires. At Series B, SOC2 Type II, SBOMs, MTTR tracking, and vendor assessments become normal. At growth stage, the company needs a broader AppSec programme with regular pen tests and stronger reporting.

Security does not need to block engineering speed. The goal is to introduce the next level before customers, auditors, or investors force it under pressure.

Stage	Security Programme Components	Tooling	Estimated Cost
Seed	Basic dependency checks, committed lock files, Dependabot, owner for security updates.	`npm audit`, Dependabot, GitHub alerts.	$0-$100/month.
Series A	Continuous SCA monitoring, SOC2 Type I preparation, Jira workflow for CVEs, security champion.	Vulert Pro, Jira, SBOM generation with Syft.	$45/month for Vulert Pro plus existing workflow tools.
Series B	SOC2 Type II, SBOM per release, MTTR tracking, vendor security assessments, formal risk acceptance.	Vulert Growth, Jira, GRC platform, security reporting.	$125/month for Vulert Growth plus audit and GRC costs.
Growth	Full AppSec programme, regular pen tests, customer security evidence pack, executive dashboard.	Enterprise SCA, Jira integration, trend reports, security dashboard.	$500+/month for Vulert Enterprise plus pen test and AppSec budget.

How Vulert Fits SaaS Dependency Security

Vulert is focused on open source dependency vulnerability monitoring. It analyzes manifest files and SBOMs against 458,000+ known CVEs, alerts teams when new CVEs affect specific package versions, and provides exact fixed versions plus CLI commands. That is the practical workflow SaaS engineering teams need when a security questionnaire asks how they monitor open source components.

Vulert supports files used across SaaS stacks, including package-lock.json, yarn.lock, pnpm-lock.yaml, pom.xml, build.gradle, requirements.txt, Pipfile.lock, poetry.lock, composer.lock, go.sum, Gemfile.lock, Cargo.lock, pubspec.lock, mix.lock, *.csproj, packages.lock.json, and SBOMs in SPDX or CycloneDX formats.

For B2B SaaS CTOs, the most useful features are continuous monitoring, Dependency Health grouping, Jira ticket creation, scan history, trend reports, full CVE detail, workaround guidance, and SBOM upload. These features support enterprise questionnaires, SOC2 evidence, due diligence, and weekly engineering prioritisation.

# Example: generate an SBOM for a SaaS application release
syft dir:. -o cyclonedx-json > sbom.json

# Upload the SBOM or manifest file to Vulert:
# https://vulert.com/abom

# Example manifests Vulert can scan:
# package-lock.json
# pom.xml
# requirements.txt
# composer.lock
# go.sum
# Cargo.lock
# packages.lock.json

Security Questionnaire Answers SaaS CTOs Should Have Ready

Enterprise buyers want short, confident, evidence-backed answers. They do not want long explanations that reveal missing process. A SaaS CTO should prepare standard answers for open source security questions before procurement asks.

The strongest answers include tooling, frequency, ownership, remediation workflow, and evidence. For example, “We use continuous SCA monitoring with Vulert across all production applications. Critical findings create Jira tickets with package, CVE, fixed version, and CLI command. We track remediation history and review trend reports for audit evidence.” That answer is much stronger than “developers update packages when needed.”

Question	Weak Answer	Strong Answer
How do you monitor open source components?	Developers check manually.	We use continuous SCA monitoring across production applications with scan history and alerts.
How fast do you patch critical CVEs?	As soon as possible.	Critical CVEs follow a documented SLA, with tickets, owners, and remediation evidence.
Do you maintain an SBOM?	Not currently.	We generate CycloneDX or SPDX SBOMs for key releases and scan them for known CVEs.
Can you prove the process operates over time?	We can send a current scan.	We retain timestamped scan history, vulnerability trends, and remediation records.

To strengthen SaaS dependency security and customer evidence, continue with these Vulert guides:

ISO 27001 and Open Source Dependencies — What the Standard Actually Requires
How to Build a Vulnerability Management Dashboard for Your CTO

These guides help SaaS teams turn open source vulnerability data into audit evidence, executive reporting, and enterprise-ready security answers.

Key Takeaways

SaaS open source security is a customer trust issue because one vulnerable dependency can affect many tenants and customer datasets.
Dependency security becomes urgent during the first enterprise deal, Series B due diligence, pre-launch penetration testing, and critical CVE disclosures.
SOC2 Type II evidence requires records over time, including scan history, remediation tickets, MTTR data, and documented risk decisions.
Multi-tenant SaaS teams should re-weight vulnerability severity upward when a package affects shared authentication, billing, API security, or tenant-wide data processing.
A seed-stage SaaS company can start with free tooling, but Series A and later teams should add continuous SCA monitoring and formal remediation workflows.
Vulert helps SaaS teams answer customer security questions with continuous monitoring, SBOM upload, Jira tickets, Dependency Health grouping, and audit-ready trend reports.

Frequently Asked Questions

1. Does SOC2 require dependency scanning for SaaS?

SOC2 does not mandate a specific dependency scanner, but auditors expect evidence that security controls operate over time. For SaaS companies using open source packages, continuous SCA monitoring is a practical way to show dependency vulnerability detection, remediation, and evidence retention.

2. How does a critical CVE affect a multi-tenant SaaS differently?

A critical CVE in a multi-tenant SaaS dependency can affect all tenants at once if the vulnerable package sits in shared code. That means the blast radius is larger than a single-tenant application, and the team should prioritise shared authentication, billing, API, and data processing paths aggressively.

3. What files should a SaaS company scan for dependency vulnerabilities?

Scan the dependency files that define production applications, including package-lock.json, yarn.lock, pom.xml, build.gradle, requirements.txt, poetry.lock, composer.lock, go.sum, Gemfile.lock, Cargo.lock, *.csproj, packages.lock.json, and SBOMs in CycloneDX or SPDX formats.

How to Build a Vulnerability Management Dashboard for Your CTO

Vulert — Sun, 02 Aug 2026 07:00:00 +0000

A vulnerability management dashboard that lists 133 CVEs with CVSS scores is not a management dashboard. It is a raw export. A CTO needs the answer to 3 questions: are we getting safer, where is the risk concentrated, and what needs engineering attention this week?

This guide defines the 7 metrics a CTO-level dashboard should show, how to build the dashboard with or without a dedicated security platform, how to turn raw vulnerability data into a board-ready summary, and how Vulert can provide the underlying SCA trend data, MTTR tracking, and Dependency Health view.

Note: The best security dashboard for management is not the most detailed dashboard. It is the dashboard that shows trend, ownership, risk direction, and the next decision.

Why Current Security Reporting Fails — Two Failure Modes

Security reporting usually fails in 2 ways. The first failure is too much detail. A spreadsheet with 133 CVEs, package names, CVSS scores, descriptions, references, and raw scanner output may help an engineer investigate, but it does not help a CTO allocate people, set remediation priorities, or explain risk to the board. The more rows the report contains, the less useful it becomes for leadership decisions.

The second failure is too little detail. “Security is on track” is not a report. It gives no trend, no exposure level, no timeline, no SLA status, and no evidence. This type of vague update fails in board meetings, enterprise sales calls, cyber insurance renewals, SOC2 reviews, and ISO 27001 audits. Leadership needs a small number of metrics that show whether remediation is improving or falling behind.

The right level is 5-7 metrics. A CTO should see critical vulnerability trend, MTTR by severity, newly disclosed CVEs affecting the stack, backlog age, monitoring coverage, top package upgrades by impact, and SLA compliance. These metrics turn vulnerability management from a scanner output problem into an engineering management problem.

A CTO does not need every CVE in the first view. They need the few metrics that show risk direction, ownership, and remediation velocity.

The 7 Metrics Every Vulnerability Dashboard Should Show

A good vulnerability management dashboard must show trend, risk level, and action. A snapshot is not enough. If the dashboard says there are 18 critical vulnerabilities today, the CTO still needs to know whether that number was 3 last week or 60 last week. Direction changes the decision.

Each metric should answer a management question. Critical count answers “are we getting better or worse?” MTTR answers “how fast do we fix?” Newly disclosed CVEs answer “what changed in the threat landscape this week?” Backlog age answers “what risk are we carrying too long?” Coverage answers “are we blind anywhere?” Top packages by impact answers “where should engineering focus?” Compliance status answers “are we meeting our documented promises?”

These metrics work for open source dependency vulnerabilities, infrastructure vulnerabilities, and application security findings, but they are especially useful for SCA because package upgrades often resolve many CVEs at once. Vulert’s Dependency Health view supports this by grouping many CVEs into the few package upgrades that remove the most risk.

Metric	Management Question	Good Signal	Bad Signal
Critical vulnerability count trend	Are we getting safer?	Downward trend over 13 weeks.	Rising count or unexplained flat zero.
MTTR by severity	How fast do we fix?	Critical under 48 hours and High under 7 days.	Critical findings open longer than 7 days.
New CVEs this week	What changed externally?	Spikes are investigated quickly.	New CVEs appear with no triage owner.
Backlog by age	What old risk remains?	Few findings older than 30 days.	Growing 90-day backlog.
Coverage	Are all production apps monitored?	100% production coverage.	Unknown or partial application coverage.
Top packages by impact	Where should engineering focus?	Top 3 upgrades remove many CVEs.	Teams chase individual CVEs one by one.
SLA compliance	Are we meeting policy?	Critical CVEs resolved within target.	Repeated SLA breaches with no escalation.

1. Critical Vulnerability Count — Trending Over 13 Weeks

Critical vulnerability count should be shown as a trend line, not a single number. A 13-week view is long enough to show whether remediation is improving, stalling, or getting worse. It also avoids overreacting to one noisy week while still making deterioration visible.

A rising trend means the team is discovering or accumulating more severe risk than it is fixing. A falling trend means remediation is working. A flat line at zero can be excellent, but it can also mean scanning is broken, coverage is incomplete, or the wrong repositories are monitored. The dashboard should pair the critical count with coverage so leadership does not mistake missing data for low risk.

2. Mean Time to Remediate (MTTR) by Severity

Mean time to remediate shows how long vulnerabilities remain open after detection. It is one of the clearest security operations metrics for engineering leadership because it connects risk to delivery speed. A reasonable target is critical vulnerabilities under 48 hours, high vulnerabilities under 7 days, and medium vulnerabilities under 30 days.

If MTTR is trending up, prioritisation is broken or engineering capacity is insufficient. If critical MTTR exceeds 7 days, the CTO should treat it as a governance issue. Some exceptions are valid, such as no available fix or non-reachable code paths, but those should appear in the risk register with an owner and review date.

3. Newly Disclosed CVEs Affecting Your Stack This Week

Newly disclosed CVEs show how the external threat landscape changed for your specific packages. This metric is different from total backlog because it focuses on what became newly relevant this week. A spike may indicate a major library incident, a vulnerable ecosystem release, or a new disclosure affecting a common transitive dependency.

Log4Shell would have shown as a dramatic spike for organisations using vulnerable Log4j versions. For open source dependency monitoring, this metric helps leadership understand that vulnerability work is not always caused by engineering negligence. Sometimes the world changes overnight, and the team needs to respond.

4. Vulnerability Backlog by Age

Backlog age shows how long vulnerabilities have remained unresolved. A vulnerability open for 2 days and a vulnerability open for 180 days should not look the same. Age reveals whether remediation is keeping up or whether the team is accumulating risk.

The dashboard should show findings older than 30 days and older than 90 days. Old unresolved critical vulnerabilities are the highest-risk items. A growing 90-day backlog signals that the process is overloaded, tickets are not assigned, or teams are accepting risk without formal approval.

5. Coverage — Percentage of Applications Monitored

Monitoring coverage answers whether the dashboard is complete. If you have 20 production applications and only 12 are scanned, the dashboard has a 40% blind spot. That makes every other metric less trustworthy.

Coverage should be 100% for production applications. If some applications are excluded, the dashboard should list them by name and explain why. Coverage should include monoliths, microservices, internal tools that touch customer data, APIs, worker services, and release artifacts with dependencies.

6. Top 3 Packages by Vulnerability Impact

Dependency Health is the most actionable metric for engineering teams. Instead of asking developers to fix 133 CVEs individually, it asks which 3 package upgrades would remove the most risk today. One parent package upgrade may fix dozens of transitive CVEs.

This metric changes the conversation from “security has a long list” to “engineering should upgrade these packages first.” Vulert’s Dependency Health view supports this by grouping CVEs by package upgrade, helping teams focus on the smallest set of changes with the biggest security impact.

7. Compliance Status Against Documented SLAs

SLA compliance shows whether the team meets its documented vulnerability management commitments. For example, the dashboard can show how many critical CVEs exceeded the 48-hour SLA this month and how many high CVEs exceeded the 7-day target.

This metric supports SOC2, ISO 27001, cyber insurance renewals, and enterprise client security reviews. It also helps the CTO decide whether the process needs more automation, more engineering capacity, or clearer escalation rules.

How to Build This Without a Dedicated Security Platform

You can build a basic security dashboard for management with Google Sheets, Notion, or Jira. It will not be as automated as a dedicated platform, but it can work if the team commits to weekly updates and clear ownership. The goal is to collect the 7 metrics in one place and update them on a predictable cadence.

Start with a Google Sheet if the team is small. Create tabs for weekly summary, application coverage, open criticals, MTTR, backlog age, and top package upgrades. Populate the sheet from SCA scan reports, Jira tickets, and release records. This usually takes 30 minutes per week if the team keeps the process tight.

For Jira, create a dashboard using labels such as security, sca, critical, and high. Add issue count by priority, created versus resolved trend, average age of open issues, and SLA breach filters. Jira works best when every vulnerability finding creates a ticket with package name, CVE ID, severity, affected application, owner, due date, and fix command.

Google Sheets dashboard tabs

Executive Summary
Critical CVE Trend — 13 Weeks
MTTR by Severity
New CVEs This Week
Backlog Age
Application Coverage
Top 3 Package Upgrades
SLA Breaches
Risk Accepted Findings

Jira examples for a vulnerability dashboard

labels = security AND priority = Critical AND statusCategory != Done

labels = security AND priority in (Critical, High) AND created >= -7d

labels = security AND priority = Critical AND statusCategory != Done AND created <= -2d

labels = security AND statusCategory != Done ORDER BY created ASC

Tip: If the dashboard is manual, update it on the same day every week and keep the same metric definitions. Inconsistent measurement destroys trust.

The One-Page Board-Level Summary

A CTO security report should include a one-page summary that translates the dashboard into leadership language. Board members and enterprise clients rarely need raw scanner output. They need a concise statement of current risk, trend, coverage, and SLA performance.

The best format is one sentence per metric. Use numbers, direction, and target. Do not say “we improved vulnerability management.” Say “Critical vulnerabilities are down from 12 to 4 over the last month.” Do not say “we patch quickly.” Say “Mean time to fix critical CVEs is 37 hours against a 48-hour target.”

This format helps the CTO communicate without overloading non-technical stakeholders. It also creates repeatable evidence for audits and customer reviews. Keep the summary consistent month to month so leadership can see trend.

Board Metric	Example Sentence
Critical vulnerability count	Critical vulnerabilities this month: 4, down from 12 last month.
MTTR	Mean time to fix critical CVEs: 37 hours against a 48-hour target.
Monitoring coverage	Applications with monitoring coverage: 20 of 20 production apps, 100% coverage.
SLA compliance	Critical CVE SLA compliance: 96% resolved within 48 hours this month.
Top engineering action	The top 3 package upgrades will remove 61 open CVEs across 7 applications.

The board-ready version of vulnerability management is trend, target, coverage, and next action.

What Enterprise Clients and Auditors Check on This Dashboard

Enterprise clients and auditors check whether vulnerability management is controlled, measured, and improving. They do not expect zero vulnerabilities forever. They expect monitoring, triage, remediation, risk acceptance, and evidence. A strong dashboard helps answer these questions before they become blockers in sales or audits.

For SOC2 and ISO 27001, the dashboard supports evidence that vulnerabilities are tracked and remediated according to documented procedures. For cyber insurance, it supports answers about scan frequency, MTTR, critical patch timelines, and control maturity. For enterprise client security questionnaires, it supports answers about open source dependency monitoring and remediation ownership.

Auditors may ask for a sample vulnerability from detection to closure. The dashboard should make that easy. Click from the metric to the ticket, from the ticket to the pull request, from the pull request to the release, and from the release to the closed finding. This traceability is more valuable than a polished slide with no underlying evidence.

Monitoring evidence: The dashboard should show that scans run continuously or on a documented schedule.
Remediation records: Each significant finding should link to a ticket, owner, fix, test, and closure date.
Risk acceptance: Unfixed critical or high vulnerabilities should have formal approval, reason, expiry, and compensating controls.
Coverage proof: The dashboard should show which production applications are monitored and which are not.
Trend reports: The dashboard should show whether vulnerability counts and MTTR improve over time.

How Vulert Provides the Data Behind the Dashboard

Vulert provides the underlying SCA data needed for a vulnerability metrics dashboard. It analyzes manifest files and SBOMs against 458,000+ known CVEs, alerts teams when new CVEs affect their specific packages, and provides exact fix guidance with versions and CLI commands. This gives teams structured data instead of raw manual research.

Vulert supports common dependency files such as package-lock.json, yarn.lock, pom.xml, build.gradle, requirements.txt, Pipfile.lock, poetry.lock, composer.lock, go.sum, Gemfile.lock, Cargo.lock, pubspec.lock, mix.lock, *.csproj, packages.lock.json, and SBOMs in SPDX and CycloneDX formats. That makes it suitable for teams with JavaScript, Java, Python, PHP, Go, Ruby, Rust, Dart, Elixir, Erlang, C++, and C#/.NET projects.

The features that matter most for dashboards are continuous monitoring, timestamped scan history, vulnerability history, trend reports, Dependency Health grouping, Jira integration, and full CVE detail. A CTO does not need to inspect every CVE daily, but the dashboard needs reliable data underneath it. Vulert helps provide that data layer.

Note: Vulert focuses on open source dependency CVEs. Pair it with your broader security processes for infrastructure, cloud, identity, and application code findings.

Dashboard Template You Can Copy

The easiest way to start is to create a dashboard with fixed sections. Do not let every weekly report use a different layout. Consistency helps the CTO, board, and auditors understand trend. Use the same metric names, same time windows, same severity definitions, and same SLA targets every month.

The template below is intentionally short. It forces the security team to summarise instead of dumping raw scanner output. Add drill-down links for engineering details, but keep the executive view focused.

CTO Vulnerability Dashboard

Reporting Period:
Owner:
Coverage:
Production applications monitored: __ of __

1. Critical Vulnerability Trend
Current critical count:
13-week trend: Up / Down / Flat
Reason for change:

2. MTTR by Severity
Critical MTTR:
High MTTR:
Medium MTTR:

3. New CVEs Affecting Our Stack This Week
New Critical:
New High:
Most affected package:

4. Backlog by Age
Older than 30 days:
Older than 90 days:
Oldest critical finding:

5. Coverage
Applications monitored:
Applications missing monitoring:
Plan to close gaps:

6. Top 3 Package Upgrades by Impact
Package 1:
Package 2:
Package 3:
CVEs resolved if upgraded:

7. SLA Compliance
Critical SLA target:
Critical SLA compliance:
SLA breaches this month:
Accepted risks:

Board Summary:
Critical vulnerabilities this month: __, down/up from __.
Mean time to fix critical CVEs: __ hours, target __ hours.
Monitoring coverage: __ of __ applications.
SLA compliance: __% within target.
Top 3 upgrades remove __ CVEs.

Key Takeaways

A vulnerability management dashboard should show trend, risk direction, ownership, and action rather than raw CVE exports.
The 7 CTO-level metrics are critical count trend, MTTR by severity, new CVEs this week, backlog age, coverage, top packages by impact, and SLA compliance.
Critical vulnerability count should be shown over 13 weeks so leaders can see whether remediation is improving or falling behind.
MTTR targets should be explicit, such as critical vulnerabilities under 48 hours, high vulnerabilities under 7 days, and medium vulnerabilities under 30 days.
Coverage must be visible because a dashboard is misleading if production applications are missing from monitoring.
Vulert provides SCA trend data, new CVE detection, Dependency Health grouping, Jira integration, and scan history for audit-ready reporting.

Frequently Asked Questions

1. What metrics should a security dashboard show?

A security dashboard for management should show critical vulnerability trend, MTTR by severity, newly disclosed CVEs affecting the stack, backlog by age, monitoring coverage, top packages by impact, and SLA compliance. These metrics show both risk and remediation performance.

2. How do I report vulnerability management to my board?

Use one sentence per key metric: critical count, MTTR, coverage, SLA compliance, and top remediation action. Avoid raw CVE spreadsheets. The board needs trend, target, and decision-ready context.

3. Why is application coverage important in a vulnerability dashboard?

Coverage shows whether the dashboard reflects the whole production environment. If only 12 of 20 applications are scanned, every metric has a blind spot. CTOs should require 100% production application coverage or documented exceptions.

Cyber Insurance and Open Source Vulnerabilities — What Insurers Now Require

Vulert — Sat, 01 Aug 2026 07:40:00 +0000

Cyber insurance open source vulnerabilities questions are now standard on many insurance applications because insurers have seen the cost of known, patchable software flaws turning into ransomware, breach, and supply chain claims.

Cyber insurance used to focus on basic controls such as antivirus, firewalls, backups, and encryption. Insurers now ask deeper questions about vulnerability scanning frequency, software composition analysis, patch timelines, mean time to remediate, SBOMs, and whether your organisation can prove it acted when a critical CVE affected its software.

Warning: A “yes” answer without evidence can create problems later. Insurers increasingly expect documented controls, scan history, remediation records, and clear patch timelines.

How Cyber Insurance Requirements Changed After Log4Shell

Cyber insurance requirements changed because the market learned that many losses came from known vulnerabilities that organisations failed to identify or patch quickly. Log4Shell, SolarWinds, widespread ransomware campaigns, and repeated exploitation of public-facing software shifted underwriting from generic security checkboxes to evidence-based questions about operational security.

In 2019, many insurance applications asked broad questions: do you use antivirus, do you have a firewall, do you encrypt sensitive data, and do you back up systems? By 2024, many applications were asking about patch management timelines, vulnerability scanning frequency, software composition analysis tools, third-party component tracking, and incident response plans. The difference matters because open source dependencies sit inside your applications, not just your servers.

Software composition analysis is now relevant to insurance because it helps answer whether your organisation tracks vulnerable open source packages such as log4j-core@2.14.1, jackson-databind, lodash@4.17.20, urllib3, requests, axios, and other dependencies. If a major CVE appears and you cannot show how you identified affected applications, the insurer may view that as weak vulnerability management.

By 2024, cyber insurance applications routinely ask about vulnerability scanning frequency, MTTR, and software composition analysis tools.

The Exact Questions Insurers Ask About Open Source Security

Insurers ask open source vulnerability questions because dependency risk can be invisible until a public CVE becomes urgent. A company may have strong endpoint security and still ship applications with vulnerable packages. The underwriter wants to know whether the organisation can detect, prioritise, and remediate those packages quickly enough to reduce claim probability.

The exact wording changes by insurer, broker, industry, and company size. Chubb, AIG, Beazley, CNA, Coalition, and other cyber insurers may ask different versions of the same underlying control questions. The safest renewal strategy is to prepare evidence before the application arrives. Do not wait until the renewal deadline to discover that nobody knows your critical CVE remediation timeline.

Do you use software composition analysis tools to identify vulnerabilities in open source components? The insurer asks this to understand whether you can detect CVEs in third-party packages. If the answer is yes, name the tool and describe the process.
What is your maximum acceptable time to patch critical vulnerabilities? The insurer asks this because a vague answer means there is no documented service level agreement. Many teams use 30 days for critical CVEs, while stronger programmes target 14 days or less.
Do you maintain a Software Bill of Materials for your products? The insurer asks this because an SBOM helps prove you know which components are inside your products when a new vulnerability appears.
How frequently do you scan for known vulnerabilities? The insurer asks this because quarterly or ad hoc scanning leaves long exposure windows. Continuous or daily scanning is much stronger evidence.
What is your mean time to remediate critical vulnerabilities? The insurer asks this because actual remediation history is stronger than a written policy. MTTR shows whether the organisation fixes issues at the speed it claims.
How do you handle vulnerabilities that cannot be patched immediately? The insurer asks this because not every CVE has an immediate fix. A mature answer includes risk acceptance, compensating controls, ownership, and review dates.

Tip: Prepare a short “vulnerability management evidence pack” before renewal: SCA tool name, scan frequency, MTTR, SBOM status, patch SLA, and sample remediation tickets.

The Premium Impact — What Strong Controls Actually Save You

Cyber insurance pricing depends on many factors: company size, revenue, industry, claims history, data sensitivity, security controls, ransomware exposure, cloud footprint, and underwriting appetite. Open source vulnerability management is one part of that risk picture, but it can influence premium, exclusions, limits, and underwriting confidence.

The business logic is simple. A company that continuously monitors dependencies, patches critical CVEs quickly, keeps SBOMs, and documents remediation gives the insurer better evidence that known vulnerabilities will not remain exposed for months. A company that scans only when customers ask or cannot name its critical patch timeline looks harder to insure.

The brief’s cost example is useful for budgeting. A 50-person technology company might pay roughly $5,000-$15,000 per year without strong controls, while documented security controls including SCA monitoring may support a lower range such as $2,000-$6,000 per year. Actual premiums vary, and teams should confirm numbers with their broker. The key point remains: the premium saving can exceed the annual cost of focused SCA tooling.

Security Posture	Typical Evidence	Potential Insurance Impact	Example Annual Cost Context
Weak or undocumented controls	No SCA tool, no patch SLA, no SBOM, no MTTR data.	Higher premium, lower limits, exclusions, or rejection risk.	$5,000-$15,000 for a 50-person tech company in the brief example.
Minimum acceptable controls	Weekly scanning, documented SLA, basic component tracking, MFA.	Standard market access with fewer underwriting concerns.	Premium depends on company profile and broker negotiation.
Strong documented controls	Continuous SCA monitoring, MTTR under 14 days for critical CVEs, SBOMs, risk acceptance records.	Better underwriting story and potential premium improvement.	$2,000-$6,000 for a 50-person tech company in the brief example.

What Constitutes Adequate Controls in 2026

Cyber insurance requirements 2026 are moving toward evidence, not promises. An underwriter does not only want to hear that your team “takes vulnerabilities seriously.” They want to know how often you scan, how quickly you patch, who owns remediation, whether critical issues create tickets, and whether you can prove closure.

Minimum acceptable controls usually include vulnerability scanning at least weekly, a documented patching SLA, third-party software component tracking, and MFA across critical systems. Strong controls include continuous automated SCA monitoring, evidence-backed MTTR under 14 days for critical CVEs, SBOMs for primary products, and a formal risk acceptance process for vulnerabilities that cannot be patched immediately.

For open source dependencies, adequate controls should cover the full lifecycle. The team should identify packages through manifests or SBOMs, scan them for known CVEs, triage severity and exploitability, assign owners, fix or mitigate, create tickets, retain evidence, and review trends. Vulert supports this specific SCA evidence layer by creating scan history, alerts, fix guidance, Jira tickets, and trend reports.

Control	Minimum Acceptable	Strong / Preferred	Evidence Needed
SCA monitoring	Weekly dependency vulnerability scans.	Continuous monitoring with alerts when new CVEs affect used packages.	Scan history, alert timestamps, tool configuration, dashboard export.
Critical patch SLA	Documented 30-day target for critical vulnerabilities.	14-day or faster target with actual MTTR evidence.	Policy, tickets, PRs, release notes, closure dates.
SBOM	Component inventory or SBOM for main products.	CycloneDX or SPDX SBOM generated per release and scanned for CVEs.	SBOM files, scan reports, release artifact links.
Risk acceptance	Documented exceptions for unfixed vulnerabilities.	Risk register with owner, expiry, compensating controls, and approval.	Risk register entries and review history.
Remediation workflow	Manual tickets or backlog items for critical findings.	Pre-filled Jira tickets with package, CVE, fix version, and CLI command.	Ticket history, assignment, comments, closure evidence.
Management reporting	Ad hoc reports during renewal.	Trend reports showing vulnerability backlog and improvement over time.	Monthly reports, MTTR chart, open findings by severity.

The Log4Shell Insurance Claim Issue

Log4Shell showed why open source dependency visibility matters. The vulnerability, tracked as CVE-2021-44228, affected Apache Log4j 2 versions before 2.15.0 and triggered emergency response across software companies, enterprises, vendors, and governments. The hard part was not only patching. The hard part was finding every place Log4j existed.

Insurance issues arise when a company cannot prove reasonable action. If an organisation had no dependency inventory, no scanning process, no SBOM, no owner, and no evidence of exposure assessment for weeks, an insurer may challenge whether the company met its duty of care. Policy wording varies, and claim outcomes depend on facts, exclusions, timing, and legal interpretation. Teams should not assume every Log4Shell-related claim was automatically paid or denied.

The practical lesson is documentation. When a major CVE appears, preserve the evidence trail: alert time, affected package versions, applications reviewed, owner assignment, mitigation decision, patch PR, test result, deployment date, and closure. Even if the organisation decides a CVE is not exploitable in its environment, that assessment should be recorded.

Note: Ask your broker how your policy treats known vulnerabilities, delayed patching, supply chain incidents, and failure-to-maintain-control language.

Building Your Insurance Documentation Package

A strong renewal package makes the underwriter’s job easier. It shows that your organisation has repeatable controls, not last-minute answers. For cyber insurance open source vulnerabilities, the package should explain how you identify components, monitor CVEs, assign remediation, track MTTR, and handle exceptions.

Build this package before the renewal questionnaire arrives. Export screenshots or reports from your SCA tool, list your patch SLAs, summarise last year’s critical vulnerability remediation, include SBOM status, and provide a sample ticket from detection to closure. If you have accepted risks, include a sanitised example showing owner, reason, compensating control, and review date.

Vulert helps create much of the dependency evidence package. It scans manifests and SBOMs, provides timestamped scan history, monitors continuously for new CVEs, creates Jira tickets, shows exact fixed versions, and keeps vulnerability history and trend reports. That makes it easier to answer insurer questions with records instead of guesses.

Document your vulnerability management process: Include scan frequency, triage roles, severity thresholds, patch SLAs, and risk acceptance rules.
Export SCA monitoring evidence: Include scan history, alert timestamps, affected package reports, and proof that monitoring runs continuously.
Calculate MTTR for critical CVEs: Show discovery date, ticket date, fix date, deployment date, and closure date for recent Critical findings.
List tools in use: Include SCA, ticketing, CI/CD, SBOM generation, and incident response tools with owners and purpose.
Prepare SBOM evidence: Include CycloneDX or SPDX SBOMs for primary products where available.
Show risk acceptance records: Include approved exceptions for vulnerabilities that could not be patched immediately.
Include incident response coverage: Show that your incident response plan covers vulnerability disclosure and emergency patching.

Cyber Insurance Renewal Evidence Pack

Vulnerability management procedure
SCA tool name and scan frequency
Screenshot or export of continuous monitoring history
Critical CVE patch SLA
MTTR report for Critical and High vulnerabilities
SBOM status for primary products
Sample remediation ticket with PR and deployment evidence
Risk register entries for accepted vulnerabilities
Incident response plan section for vulnerability disclosure
Security tool inventory and owners

How Vulert Helps With Cyber Insurance SCA Evidence

Cyber insurance SCA evidence needs to show more than “we ran a scan once.” It should show ongoing monitoring, affected package details, remediation guidance, ticket creation, and historical trend data. Vulert is built for that open source dependency layer.

Vulert analyzes manifest files and SBOMs against 458,000+ known CVEs. It supports package-lock.json, yarn.lock, pom.xml, build.gradle, requirements.txt, Pipfile.lock, poetry.lock, composer.lock, go.sum, Gemfile.lock, Cargo.lock, pubspec.lock, mix.lock, *.csproj, packages.lock.json, and SBOMs in SPDX and CycloneDX formats.

For renewal evidence, Vulert provides timestamped scan history, continuous monitoring, exact fixed versions, CLI fix commands, Dependency Health grouping, one-click Jira ticket creation, full CVE detail, workaround notes, vulnerability history, and trend reports. These records help answer insurer questions about scan frequency, remediation process, and whether the organisation tracks open source risk after deployment.

Timestamped alerts: These records show when the organisation learned that a dependency became vulnerable.
Scan history: This evidence shows monitoring over time rather than a one-off renewal scan.
Fix guidance: This helps developers remediate quickly with exact fixed versions and CLI commands.
Jira tickets: These connect insurer questions to actual remediation ownership and closure evidence.
Trend reports: These help show whether vulnerability backlog and MTTR are improving.

Common Mistakes That Increase Insurance Risk

Many teams weaken their insurance position by giving vague answers. “We patch quickly” is not a measurable control. “We scan regularly” is not enough unless you can define frequency and show evidence. “Engineering handles it” is not a process unless ownership, SLA, ticketing, and closure records exist.

The second mistake is scanning only infrastructure and ignoring application dependencies. Infrastructure vulnerability scans may find exposed servers and OS packages, but they may not fully identify application-level dependencies declared in files such as package-lock.json, pom.xml, requirements.txt, or SBOMs. Underwriters asking about open source components expect an answer about application dependencies, not only servers.

The third mistake is having no formal exception process. Some vulnerabilities cannot be patched immediately because no fix exists, the package is deeply embedded, or the upgrade breaks compatibility. That is acceptable only if the organisation documents risk acceptance, compensating controls, owner, approval, and review date.

Warning: Do not answer insurer questionnaires optimistically. Answer based on controls you can prove with records.

Internal Links for Related Vulert Reading

To strengthen your cyber insurance evidence package, continue with these Vulert guides:

ISO 27001 and Open Source Dependencies — What the Standard Actually Requires
Software Supply Chain Security — A Complete Guide for Engineering Teams

These guides explain how dependency monitoring supports audit evidence, security questionnaires, supply chain visibility, and structured vulnerability management.

Key Takeaways

Cyber insurance open source vulnerabilities questions now commonly cover SCA tools, scan frequency, patch timelines, MTTR, SBOMs, and risk acceptance.
Insurers tightened requirements after ransomware campaigns, Log4Shell, SolarWinds, and repeated exploitation of known patchable vulnerabilities.
Minimum acceptable controls usually include at least weekly vulnerability scanning, a documented patch SLA, component tracking, and MFA.
Strong controls include continuous SCA monitoring, MTTR under 14 days for critical CVEs, SBOMs for primary products, and formal risk acceptance records.
Premium impact varies, but documented controls can improve underwriting confidence and may reduce premiums or exclusions.
Vulert helps build the SCA evidence trail through scan history, alerts, fix guidance, Jira tickets, vulnerability history, and trend reports.

Frequently Asked Questions

Do cyber insurers require vulnerability scanning?

Many cyber insurers now ask whether vulnerability scanning is performed, how often it runs, and how findings are remediated. For software companies, this increasingly includes open source dependency scanning through SCA tools, not only infrastructure scanning.

How does SCA monitoring affect cyber insurance premiums?

SCA monitoring can improve your underwriting story because it shows that your organisation tracks open source vulnerabilities continuously and can produce remediation evidence. Premium impact varies by insurer and company risk profile, but documented controls may support better terms than vague or manual processes.

What is MTTR and why do insurers ask for it?

MTTR means mean time to remediate. Insurers ask for it because it shows how quickly your organisation fixes vulnerabilities in practice, not just what the policy says. A strong programme can show MTTR for Critical and High findings with ticket and deployment evidence.

Did cyber insurers pay Log4Shell claims?

Claim outcomes depend on policy wording, facts, exclusions, timing, and whether the insured organisation maintained reasonable controls. Some claims may be disputed if the organisation cannot show that it had a process to identify exposure and act on known vulnerabilities.

What documents should I prepare for cyber insurance renewal?

Prepare your vulnerability management procedure, SCA monitoring evidence, scan history, MTTR report, patch SLA, SBOM status, sample remediation tickets, risk acceptance records, and incident response plan section for vulnerability disclosure.

Build the Evidence Trail Your Insurer Asks For

Cyber insurance applications now ask for proof: scan frequency, patch timelines, MTTR, SBOMs, and remediation records. Vulert helps teams create that open source vulnerability evidence trail through continuous monitoring and timestamped reports.

Scan your dependencies free at vulert.com/abom — upload your manifest file and see every vulnerability with exact fix commands in 60 seconds. No signup required.

ISO 27001 and Open Source Dependencies — What the Standard Actually Requires

Vulert — Sat, 01 Aug 2026 07:00:00 +0000

ISO 27001 open source dependency management is not about proving that every package is perfect. It is about proving that your organisation can identify technical vulnerabilities, assess exposure, take action, and retain evidence.

ISO/IEC 27001:2022 is the current version of the international information security management standard. This guide focuses only on the clauses and Annex A controls that relate to open source dependency vulnerability management, SCA monitoring, SBOM evidence, remediation records, and audit preparation.

Note: This is not a full ISO 27001 implementation guide. It covers the dependency security evidence auditors expect when your software uses open source packages.

ISO 27001:2022 — The Current Version and What Changed

ISO/IEC 27001:2022 replaced the previous 2013 version and is now the version companies should reference for new certification work. Organisations that held older certifications had a transition period to move to the 2022 revision. For engineering teams, the important change is not only the control numbering. The 2022 version makes it easier to map modern security processes to current technology risk, including cloud services, software installation, change management, and vulnerability management.

For open source dependencies, ISO 27001 does not say “use this exact SCA vendor” or “generate this exact SBOM format.” Instead, it expects a risk-based management system. You need a documented process for identifying vulnerabilities in information systems, assessing whether they affect your organisation, and taking appropriate action. That process must produce evidence. A quarterly manual spreadsheet is usually weak evidence because new CVEs appear every day and dependency risk changes after deployment.

This is where software composition analysis becomes relevant. SCA tools help identify vulnerable packages in files such as package-lock.json, pom.xml, requirements.txt, composer.lock, go.sum, Cargo.lock, and SBOMs. The tool does not make you ISO 27001 certified by itself, but it helps create the monitoring and remediation evidence that supports your ISMS.

Auditors usually care less about the tool name and more about the repeatable process, evidence, ownership, and risk treatment decisions.

The Controls That Directly Cover Open Source Dependency Security

Open source dependencies connect to several ISO 27001:2022 controls. The most direct one is Control 8.8, Management of Technical Vulnerabilities. This control aligns closely with dependency vulnerability monitoring because open source packages are part of the information systems your organisation uses. If your application includes log4j-core@2.14.1, lodash@4.17.20, urllib3, jackson-databind, or axios, those packages become part of your technical risk surface.

Dependency upgrades also relate to change management. When developers patch a vulnerable package, they are changing production software. That change should follow your normal engineering workflow: pull request, review, automated tests, deployment approval where required, and release evidence. SCA alerts should therefore connect to tickets, pull requests, commits, test results, and deployment records.

Third-party SCA tools also create a cloud service consideration. If your organisation uses Vulert, Snyk, Mend, GitHub Advanced Security, or another SaaS scanner, you should assess that tool as a supplier or cloud service under your security process. Finally, software installation controls matter because adding a new package is a form of software introduction into your environment.

ISO 27001:2022 Area	Dependency Security Meaning	Evidence to Keep
Control 8.8 — Management of Technical Vulnerabilities	The organisation identifies, assesses, and treats vulnerabilities in open source packages.	SCA alerts, scan history, CVE reports, remediation tickets, risk register entries.
Control 8.32 — Change Management	Dependency upgrades for security fixes follow the approved engineering change process.	Pull requests, approvals, test results, deployment logs, release notes.
Control 5.23 — Information Security for Use of Cloud Services	SCA platforms used as SaaS tools are reviewed as cloud services.	Vendor review, access control records, data handling notes, service owner approval.
Control A.8.19 — Installation of Software on Operational Systems	New dependencies are evaluated before being added to production software.	Dependency approval notes, package review checklist, SBOM updates, security tickets.

Control 8.8 — Management of Technical Vulnerabilities

Management of technical vulnerabilities is the control most directly tied to open source dependency security. For dependencies, the practical requirement is simple: know when a package you use becomes vulnerable, decide whether the vulnerability affects you, and take appropriate action. Appropriate action may mean patching, upgrading, applying a workaround, removing the package, or formally accepting risk with documented justification.

The key word for auditors is evidence. A team should be able to show when a CVE was detected, which application used the affected package, who owned remediation, which fix version was available, when the fix was applied, and whether any residual risk remained. For example, if CVE-2021-44228 affected a Java service using log4j-core@2.14.1, the audit trail should show detection, triage, upgrade to a safe Log4j version, test evidence, deployment date, and closure.

For ISO 27001 open source dependency processes, continuous or near-continuous monitoring is much stronger than ad hoc manual checking. New CVEs are disclosed after software is deployed. A package that scanned clean last month may become vulnerable today. A documented SCA process gives auditors a clear control story: package inventory, vulnerability feed, alert, assessment, remediation, verification, and retained record.

Control 8.32 — Change Management for Dependency Upgrades

Change management applies when a dependency upgrade changes production software. Security patches can still break applications. A vulnerable package may require a major version upgrade, API change, lock file change, or parent package upgrade. That means the vulnerability management process must connect to your engineering change process.

For most software teams, the practical evidence is a pull request. The PR shows the package version change, lock file update, reviewer approval, CI test result, and merged commit. A Jira ticket or GitHub issue can show why the change happened, which CVE it fixed, and when it was deployed. This creates an audit trail without adding heavy bureaucracy.

For example, if a Node.js project upgrades axios because a vulnerable transitive package is present, the change record should include the old version, new version, test status, owner, and deployment date. The auditor does not need a 20-page document for each dependency. They need consistent evidence that security changes are controlled, reviewed, and traceable.

Control 5.23 — Cloud Services Including SCA Tools

Cloud service security matters when your organisation uses a SaaS tool to scan dependency files, store vulnerability records, send alerts, or create remediation tickets. SCA tools process information about your software components, repositories, package files, SBOMs, and vulnerability posture. That makes them part of your supplier and cloud service review process.

The review does not need to be complicated for every tool, but it should exist. Record who approved the tool, what data it receives, who has access, how authentication works, whether SSO or 2FA is enabled, and how alerts are used. If the tool integrates with Jira, GitHub, GitLab, or Slack, include those integrations in the review.

Vulert works with manifest files and SBOMs rather than requiring access to proprietary source code. That can simplify security review for teams that want dependency visibility without handing over full code access. Still, the organisation should document the tool as part of its ISO 27001 cloud service inventory.

Control A.8.19 — Software Installation Controls

Software installation controls apply to the packages added to operational systems. In modern development, installing software often means adding an npm package, Maven artifact, PyPI package, Composer package, Go module, Ruby gem, Rust crate, or .NET package. A single line in a manifest can bring in hundreds of transitive dependencies.

A practical control is a package approval process. Teams do not need a security committee for every package, but they should define review rules. For example, block packages with known critical CVEs, unknown maintainers, abandoned release history, suspicious install scripts, or no clear business need. Require extra review for packages added to authentication, payment, encryption, or customer data flows.

This control also supports SBOM generation. If you generate an SBOM for each release, you can show which components were installed and used at the time of deployment. That inventory supports both vulnerability response and audit evidence.

What ISO 27001 Auditors Will Actually Ask For

Auditors usually ask practical questions. They want to see that your vulnerability management process exists, runs regularly, produces evidence, and leads to action. They also want to see that exceptions and accepted risks are not hidden in chat messages or forgotten spreadsheets. Open source dependency security should therefore be tied to documented procedures, tickets, reports, and risk records.

Expect the auditor to ask for examples. They may ask you to show a recent vulnerability finding, explain how the team assessed it, prove who owned it, show the remediation ticket, and demonstrate closure. If the vulnerability was not fixed, they may ask for the risk acceptance record, compensating controls, and approval. This is where automated scan history and timestamped alerts become useful.

Show us your vulnerability management process: Provide the documented procedure that explains how dependency vulnerabilities are identified, assessed, assigned, remediated, or accepted.
Show us evidence of monitoring: Provide SCA scan history, alerts, dashboards, or reports showing that open source dependencies are monitored for new CVEs.
Show us a recent remediation record: Provide a ticket, pull request, test result, and deployment record for a recent dependency vulnerability fix.
Show us accepted vulnerability risks: Provide risk register entries for vulnerabilities that were not patched immediately, including owner, reason, expiry, and approval.
Show us timeline evidence: Provide dates from discovery to triage, remediation, deployment, and closure for recent Critical or High findings.
Show us the asset or component inventory: Provide manifests, SBOMs, repository lists, or application inventories showing what components are in scope.

Tip: Prepare 3 worked examples before the audit: one fixed dependency CVE, one accepted risk, and one false positive or non-applicable finding.

The Documentation ISO 27001 Requires for Dependency Security

ISO 27001 expects a management system, not random tool output. For dependency security, that means you should document the process from package inventory to remediation evidence. The document does not need to be long, but it should be clear enough that engineers, security, management, and auditors understand how the process works.

A useful dependency vulnerability management procedure should define scope, roles, monitoring frequency, severity criteria, triage workflow, remediation timelines, risk acceptance rules, change management links, and evidence retention. If you use an SCA tool, name it. If you generate SBOMs, state when they are created and where they are stored. If you create Jira tickets, describe how they are assigned and closed.

The policy should also define what happens when no fix is available. Some CVEs have no immediate patch. In that case, the team should record compensating controls, exposure analysis, workaround steps, or risk acceptance. For example, a vulnerable package may exist only in a dev dependency, or the vulnerable code path may not be reachable. That assessment should be documented.

Document	Purpose	Example Evidence
Vulnerability management procedure	Defines how vulnerabilities are monitored, assessed, treated, and recorded.	Approved policy, owner, review date, workflow diagram.
Dependency inventory	Shows which packages and versions are used by each application.	Manifest files, lock files, SBOMs, Vulert scan reports.
Remediation records	Shows that vulnerabilities were fixed through controlled changes.	Jira tickets, pull requests, tests, deployment records.
Risk register	Tracks vulnerabilities that are accepted, deferred, or mitigated.	Risk owner, reason, expiry date, approval, compensating controls.
Trend reports	Shows management oversight and improvement over time.	Open findings by severity, time to remediate, recurring packages.

How Continuous Monitoring Satisfies Control 8.8

Continuous monitoring helps satisfy the practical evidence requirements behind Control 8.8 because dependency risk changes after deployment. A package can be safe at release time and vulnerable a week later when a new CVE becomes public. Manual quarterly checks create long blind spots. Continuous SCA monitoring reduces that gap and creates an audit trail.

Vulert monitors open source dependencies by analyzing manifest files and SBOMs against 458,000+ known CVEs. It alerts teams when vulnerabilities are found or when new CVEs affect specific package versions. It also provides exact fixed versions, CLI commands, Dependency Health grouping, Jira ticket creation, full CVE detail, workaround information, vulnerability history, and trend reports.

For ISO 27001 evidence, the useful part is traceability. A timestamped alert shows when the organisation became aware of a vulnerability. Scan history shows what was found and when. Remediation records show what changed. Jira tickets show ownership. Trend reports show whether the backlog is improving. Together, these artifacts support the story auditors need to hear: the organisation obtains timely information, assesses exposure, and takes appropriate action.

# Example dependency evidence workflow

# 1. Generate an SBOM for a release
syft dir:. -o cyclonedx-json > sbom.json

# 2. Upload sbom.json or your manifest file to Vulert
# https://vulert.com/abom

# 3. Create remediation tickets for Critical and High findings

# 4. Upgrade packages through pull requests and retain test evidence

# 5. Keep scan history and trend reports for ISO 27001 audit evidence

ISO 27001 Dependency Security Process Template

The following template can help teams describe dependency security in ISO 27001-compatible language. Adapt it to your organisation, risk appetite, product architecture, and engineering workflow. The goal is to show that open source dependency vulnerabilities are identified, assessed, treated, documented, and reviewed.

Keep the template short enough that the team actually follows it. A process that looks perfect but never runs is weak audit evidence. A simple procedure that runs every week, creates tickets, and closes findings is much stronger. Connect the template to existing engineering tools such as GitHub, GitLab, Jira, Slack, CI/CD, and release notes.

Dependency Vulnerability Management Procedure

Scope:
All production applications, maintained repositories, and release artifacts that use open source dependencies.

Inventory:
Each application must retain supported manifest files, lock files, or SBOMs showing direct and transitive dependencies.

Monitoring:
Dependencies are monitored continuously using an approved SCA process. New Critical and High CVEs are reviewed when alerts are received.

Triage:
Security or engineering reviews each finding for affected package, installed version, reachable code path, exploitability, and business exposure.

Remediation:
Vulnerabilities are patched by upgrading to a fixed version, applying a workaround, removing the package, or replacing the dependency.

Change Control:
Dependency upgrades are performed through pull requests with review, automated testing, and deployment evidence.

Risk Acceptance:
Unresolved vulnerabilities require a risk register entry with owner, reason, compensating controls, approval, and review date.

Evidence:
Scan history, alerts, tickets, pull requests, test results, deployment records, SBOMs, and trend reports are retained for audit review.

Note: This template is a starting point. Align timelines, severity thresholds, and approval rules with your own ISMS and risk treatment process.

How SBOMs Support ISO 27001 Vulnerability Management

Software bill of materials files are not explicitly required by ISO 27001, but they strongly support vulnerability management evidence. Control 8.8 expects the organisation to obtain timely information about vulnerabilities in systems being used. To do that well, you need to know which components those systems contain.

An SBOM provides a formal component inventory for a product, build, or release. It can show direct and transitive dependencies, package names, versions, suppliers, and identifiers. When a major vulnerability appears, the organisation can search SBOMs to determine whether affected packages exist in any release. This is much faster than asking every engineering team to manually inspect repositories during an incident.

Vulert accepts CycloneDX and SPDX SBOM uploads. That helps teams use SBOMs as part of their ISO 27001 evidence workflow: generate SBOM, scan for CVEs, create remediation tickets, retain scan history, and show trend reports. For enterprise sales, this can also support customer security questionnaires that ask how the company tracks open source dependency risk.

SBOM Use Case	ISO 27001 Value	Evidence Example
Release inventory	Shows which components were present in a specific release.	CycloneDX or SPDX file stored with release artifacts.
CVE response	Helps determine whether a newly disclosed CVE affects the organisation.	SBOM scan report showing affected and unaffected components.
Audit evidence	Shows a repeatable process for component visibility and vulnerability review.	Timestamped scan history and remediation records.
Customer security review	Supports answers about dependency inventory and vulnerability monitoring.	Trend report, SBOM policy, and sample remediation ticket.

Common Mistakes That Fail ISO 27001 Dependency Reviews

Teams often fail dependency reviews because they confuse scanning with management. A scan report is useful, but it is not enough by itself. The organisation also needs triage, ownership, remediation, change control, risk acceptance, and management review. If the same Critical finding appears for months without an owner or risk record, the tool output becomes evidence of weak process.

The second mistake is scanning only before release. Open source vulnerabilities are disclosed continuously. If a package becomes vulnerable after deployment, a pre-release scan will not catch it unless the team scans again or has continuous monitoring. This is why “timely information” matters in practice.

The third mistake is poor evidence retention. Teams fix vulnerabilities but lose the audit trail because the conversation happened in Slack, the PR description was empty, or the ticket was deleted. ISO 27001 evidence should survive normal engineering churn. Keep tickets, scan history, release notes, and risk records organised by application and date.

Scan-only thinking: A scan report without ownership, remediation, or risk treatment does not prove effective vulnerability management.
Quarterly blind spots: Manual scans every few months can miss CVEs disclosed after deployment.
Missing risk acceptance: Deferred vulnerabilities should have a documented owner, reason, compensating control, and review date.
Uncontrolled upgrades: Emergency dependency updates should still leave pull request, test, and deployment evidence.
No component inventory: Teams cannot assess exposure quickly if they do not know which packages and versions are in use.

To strengthen your ISO 27001 dependency security evidence, continue with these Vulert guides:

How to Generate an SBOM — Tools and Commands for Every Language
Software Supply Chain Security — A Complete Guide for Engineering Teams

These guides help teams build the component inventory and supply chain visibility needed for stronger vulnerability management evidence.

Key Takeaways

ISO 27001 open source dependency security maps most directly to Control 8.8, Management of Technical Vulnerabilities.
ISO 27001:2022 expects organisations to identify vulnerabilities, assess exposure, take appropriate action, and retain evidence.
Dependency upgrades also connect to Control 8.32 because security patches change production systems and should follow change management.
SCA tools used as SaaS platforms should be reviewed under cloud service and supplier security processes.
SBOMs are not explicitly required by ISO 27001, but they provide strong evidence of component visibility and vulnerability response maturity.
Vulert supports ISO 27001 vulnerability evidence through timestamped scan history, CVE alerts, remediation guidance, Jira tickets, and trend reports.

Frequently Asked Questions

1. Does ISO 27001 require dependency scanning?

ISO 27001 does not name a specific dependency scanner, but Control 8.8 requires a process for obtaining vulnerability information, assessing exposure, and taking action. For software teams using open source packages, SCA scanning is a practical way to produce that evidence.

2. How does an SBOM help with ISO 27001 compliance?

An SBOM helps by documenting which components exist in a product or release. When a new CVE is disclosed, the SBOM helps determine whether the affected package is present, which supports timely exposure assessment and audit evidence.

3. Can Vulert make a company ISO 27001 compliant?

No single tool makes a company ISO 27001 compliant. Vulert supports the dependency vulnerability monitoring and evidence layer by providing CVE alerts, scan history, remediation guidance, Jira ticket creation, and trend reports. The organisation still needs a complete ISMS, risk process, change management, ownership, and audit controls.

Open Source Licence Risk — When Your Dependencies Create Legal Problems

Vulert — Fri, 31 Jul 2026 07:30:00 +0000

Note: This post is a practical technical and business guide, not legal advice. Consult a qualified lawyer for your specific licence compliance obligations.

Open source licence risk becomes real when a developer adds one dependency and the legal team later discovers GPL, AGPL, or restrictive commercial terms hidden somewhere in the dependency tree.

Most developers understand permissive licences such as MIT. Fewer understand how GPL, AGPL, LGPL, MPL, or Business Source Licence terms can affect a commercial product, SaaS platform, funding round, acquisition, or enterprise customer review. This guide explains the licence categories, transitive risk, common conflict scenarios, tooling, and what Vulert does and does not cover.

Warning: Do not treat licence review as a one-time checklist. Dependencies change, transitive packages change, and licence terms can change across versions.

The Five Licence Categories Every Developer Should Know

Developers do not need to memorise every open source licence, but they should understand the categories that create business decisions. The difference between MIT and AGPL is not cosmetic. One usually allows commercial use with attribution. The other can create source disclosure obligations for network-accessible software under certain conditions.

Permissive licences are generally the easiest for commercial teams to use. MIT, Apache 2.0, BSD, and ISC typically allow use, modification, distribution, and commercial use with notice requirements. Apache 2.0 also includes explicit patent terms, which many enterprise legal teams like. These licences rarely create the same product-level obligations as strong copyleft licences.

Weak copyleft licences such as LGPL and MPL create more specific obligations. LGPL often permits linking from proprietary software, but modifications to the LGPL library itself may need to be shared. MPL applies copyleft at file level, which means modifications to MPL-covered files may need to stay under MPL while separate proprietary files can remain closed.

Strong copyleft licences such as GPL v2 and GPL v3 create the most concern for distributed commercial products. If a product incorporates GPL-covered code in a way that triggers GPL obligations, the product may need to be distributed under GPL terms. Network copyleft, especially AGPL v3, extends concern to SaaS because users interact with the software over a network.

Licence	Type	Commercial Use	Copyleft Trigger
MIT	Permissive	Generally allowed with copyright notice.	No broad copyleft trigger.
Apache 2.0	Permissive	Generally allowed with notice and licence terms.	No broad copyleft trigger, with patent terms included.
BSD 2-Clause / 3-Clause	Permissive	Generally allowed with attribution conditions.	No broad copyleft trigger.
ISC	Permissive	Generally allowed and similar to MIT.	No broad copyleft trigger.
LGPL	Weak copyleft	Often usable in proprietary software with conditions.	Modifying the LGPL library itself can require sharing those changes.
MPL	Weak copyleft	Often usable with proprietary code in separate files.	Modifications to MPL-covered files must usually remain under MPL.
GPL v2 / GPL v3	Strong copyleft	Commercial use may be possible, but distribution obligations can apply.	Distributed software incorporating GPL code may need source availability under GPL terms.
AGPL v3	Network copyleft	High-risk for SaaS unless legally reviewed.	Network users may trigger source availability obligations.
BSL / BUSL	Commercial source-available	Depends on the exact terms and change date.	Restrictions may apply to competing services or production use.

Licence risk is not only about whether code is open source. It is about what obligations attach when you use, modify, distribute, or provide access to that code.

The Transitive Licence Problem — The Risk You Cannot See Directly

The transitive licence problem follows the same logic as transitive vulnerability risk. You might not knowingly install a GPL package, but a dependency you use might depend on one. If package-a uses MIT and depends on package-b under GPL, your application may indirectly include GPL-covered code.

This matters because developers usually review direct dependencies, not every package several layers deep. A JavaScript application may list 25 direct dependencies but install 1,200 total packages through transitive dependencies. A Maven project may add one framework starter and pull dozens of JAR files. A Python project may add one ML or web framework package and inherit many libraries maintained by different teams under different licences.

Licence scanning must therefore inspect the full dependency tree. Reviewing only package.json, requirements.txt, or pom.xml is not enough. Teams need lock files, resolved dependency graphs, SBOMs, and licence metadata. The same inventory that helps security teams find CVEs also helps legal and compliance teams identify licence obligations.

The most dangerous licence issues often appear during due diligence, not during development. A company may ship for years without formal licence review, then discover a problematic AGPL or GPL dependency during a funding round, acquisition, customer security review, or enterprise procurement process.

Tip: Treat licence review like vulnerability review: scan direct and transitive dependencies, assign ownership, and repeat it whenever dependencies change.

The Three Licence Scenarios That Create Real Business Problems

Open source legal risk becomes serious when licence obligations conflict with your business model. Many open source licences are friendly to commercial use, but some create obligations that product, engineering, and legal teams must understand before shipping. The most common conflict scenarios involve AGPL in SaaS, GPL in distributed software, and Business Source Licence restrictions in products that compete with the licensor.

These scenarios do not always mean “you cannot use the package.” They mean “you need review before use.” Sometimes the answer is to replace the package. Sometimes dynamic linking or unmodified library use changes the risk. Sometimes the company can purchase a commercial licence. Sometimes the package is safe in internal tooling but risky in distributed customer software.

AGPL and SaaS Products

AGPL v3 is often described as the GPL for network software. If you modify or use AGPL-covered code in software that users access over a network, you may need to provide source code under AGPL terms. This makes AGPL especially sensitive for SaaS companies because SaaS users interact with the product without receiving a traditional software download.

Some historical versions or editions of tools associated with databases, dashboards, or infrastructure software have used AGPL or moved across licence models over time. Developers should not assume that a package is acceptable because it is popular. They should check the exact package, exact version, exact use case, and exact licence terms.

GPL in Distributed Software

GPL licence compliance becomes especially important when a company distributes a compiled product, desktop app, mobile app, appliance, SDK, or embedded device containing GPL-covered code. Distribution can trigger obligations to provide source code under GPL terms for the covered work.

This is why embedded, desktop, and commercial software vendors often have strict policies around GPL dependencies. A SaaS-only company may focus heavily on AGPL, while a device manufacturer may focus heavily on GPL. The risk depends on how the software is used and whether it is distributed.

Business Source Licence and Competing Products

Business Source Licence, often written as BSL or BUSL, is a source-available commercial licence used by several infrastructure companies. Elasticsearch moved away from Apache 2.0 after version 7.10. HashiCorp changed Terraform to BUSL in 2023, which contributed to enterprise concern and the creation of OpenTofu as an open source fork.

BSL terms vary by project. They often allow many uses but restrict offering the software as a competing service or product. They may also convert to an open source licence after a change date. Teams should read the exact terms instead of treating all source-available licences as equivalent.

Scenario	Common Risk	Practical Response
SaaS company uses AGPL code.	Network copyleft obligations may affect the SaaS application.	Ask legal to review and consider replacing the package.
Company distributes a product containing GPL code.	GPL source availability obligations may apply to the distributed product.	Review usage, linking, distribution model, and alternatives.
Company uses BSL software in a competing product.	The licence may prohibit competitive hosted or commercial use.	Read the specific BSL terms and seek a commercial licence if needed.

How to Check Your Dependency Licences

Teams should check dependency licences with ecosystem-specific tools and then review high-risk results manually. Licence metadata can be incomplete, inconsistent, or wrong. A scanner may report UNKNOWN, dual licences, conflicting package metadata, or a licence expression that needs interpretation. Treat tooling as an inventory step, not a legal conclusion.

For JavaScript, license-checker can scan npm dependencies. For Python, pip-licenses can list installed package licences. For Java and Maven, the Maven licence plugin can aggregate third-party licence information. For .NET, dotnet-project-licenses can help inspect NuGet dependencies. FOSSA provides paid licence compliance workflows, and the REUSE tool can support SPDX-based licence metadata management.

The strongest approach is to run licence checks in CI, export results, and send high-risk findings to legal or compliance review. Do not block every unknown result immediately. Start by blocking or reviewing strong copyleft, AGPL, unknown licences, and commercial source-available licences in production code.

# npm / JavaScript
npm install -g license-checker
license-checker --summary

# Python
pip install pip-licenses
pip-licenses

# Java / Maven
mvn license:aggregate-add-third-party

# .NET
dotnet tool install --global dotnet-project-licenses
dotnet-project-licenses --input ./YourProject.csproj

# SPDX / REUSE
pipx install reuse
reuse lint

Note: Licence tools help you find packages that need review. They do not replace advice from a lawyer who understands your product, distribution model, and customer contracts.

What to Do When You Find a Problematic Licence

Finding a problematic licence does not always mean panic. It means the team needs a controlled decision. The right response depends on the licence, how the dependency is used, whether the software is distributed, whether users access it over a network, whether the package was modified, and whether alternatives exist.

The first option is replacement. If an AGPL package creates unacceptable SaaS risk, find a permissively licensed alternative. If a GPL library appears in a distributed product, consider replacing it with MIT, Apache 2.0, BSD, or commercial alternatives. The second option is usage adjustment. An LGPL library may be acceptable if dynamically linked and unmodified, depending on your legal advice. The third option is a commercial licence exception from the maintainer or vendor.

Document the decision. A due diligence reviewer will want to know when the package was found, who reviewed it, what the risk was, what action was taken, and whether the package remains in production. A spreadsheet is better than nothing, but a repeatable process with scan outputs, SBOMs, ticket history, and approvals is stronger.

Identify the exact package and version: Licence obligations can change between versions, so record the exact dependency and resolved version.
Determine direct or transitive use: Find whether your code imports the package directly or whether another package pulls it in.
Check how the software is used: Usage in internal tooling, SaaS backend, distributed software, SDKs, and embedded devices can create different risk profiles.
Find a permissive alternative: Prefer MIT, Apache 2.0, BSD, or ISC alternatives when the existing licence creates unacceptable risk.
Consider commercial licensing: Ask the maintainer or vendor whether a paid commercial licence or exception is available.
Consult legal counsel: Ask a lawyer experienced in open source licensing before shipping or distributing high-risk combinations.
Record the decision: Keep evidence of review, remediation, acceptance, replacement, or commercial licensing for future audits.

Licence Risk During Due Diligence — What Investors and Acquirers Check

Licence issues often surface during due diligence because investors and acquirers need to understand whether the company owns or can legally commercialise its software. They may ask for a dependency inventory, SBOM, open source policy, licence scan results, high-risk package list, GPL or AGPL usage, and evidence of remediation.

A due diligence team may not object to open source use. Most modern products depend heavily on open source. The concern is unmanaged open source. If the company cannot say which packages it uses, which licences apply, whether GPL or AGPL exists in production, or who approved exceptions, the risk looks uncontrolled.

Transitive dependencies create the hardest questions. A team may confidently state that it did not intentionally add GPL code, then a scan reveals GPL or AGPL several layers deep. That does not automatically kill a deal, but it creates work, delays, and uncomfortable legal review. The earlier a company builds inventory and review practices, the easier diligence becomes.

Dependency inventory: Reviewers want a list of direct and transitive dependencies used in production products.
Licence scan results: Reviewers look for GPL, AGPL, LGPL, unknown, custom, or commercial source-available licences.
Exception records: Reviewers ask whether high-risk licences were approved, replaced, or commercially licensed.
SBOM evidence: Reviewers may request CycloneDX or SPDX SBOMs for major products and releases.
Remediation history: Reviewers prefer evidence that the company found, fixed, or accepted licence risk through a controlled process.

What Vulert Covers and What It Does Not

Vulert focuses on security vulnerabilities, not licence compliance. It analyzes manifest files and SBOMs against 458,000+ known CVEs, alerts teams when new CVEs affect their package versions, and provides exact fixed versions with CLI commands. That is security vulnerability monitoring, not legal licence analysis.

For licence compliance scanning, use a dedicated tool such as FOSSA, ecosystem tools like license-checker or pip-licenses, SPDX-based workflows, REUSE, and manual legal review. This distinction matters because a dependency can be legally risky without having a CVE, and a dependency can have a CVE while being licensed permissively.

Vulert still helps with the inventory foundation. Security and licence review both start with the same basic question: what packages are we running? Vulert accepts manifest files and SBOMs such as package-lock.json, yarn.lock, pom.xml, build.gradle, requirements.txt, poetry.lock, composer.lock, go.sum, Gemfile.lock, Cargo.lock, pubspec.lock, mix.lock, *.csproj, packages.lock.json, and SPDX or CycloneDX SBOMs.

Warning: Do not use Vulert as a licence compliance tool. Use it for CVE monitoring and use licence-specific tools or legal review for licence obligations.

To strengthen dependency visibility and security review, continue with these Vulert guides:

How to Generate an SBOM — Tools and Commands for Every Language
Software Supply Chain Security — A Complete Guide for Engineering Teams

These guides explain how to create a component inventory and how that inventory supports broader supply chain security, vulnerability monitoring, and audit readiness.

Key Takeaways

Open source licence risk comes from the obligations attached to dependencies, not from open source use itself.
Permissive licences such as MIT, Apache 2.0, BSD, and ISC are usually easier for commercial teams to use than strong copyleft licences.
GPL and AGPL require careful review because distribution or network access can trigger obligations depending on the use case.
Transitive dependencies can introduce GPL, AGPL, LGPL, unknown, or commercial source-available licences even when direct dependencies look safe.
Licence scanning should include direct and transitive dependencies, lock files, SBOMs, and manual review for high-risk findings.
Vulert monitors security CVEs, not licence compliance, but dependency inventory supports both security review and licence audit preparation.

Frequently Asked Questions

1. Does AGPL apply to SaaS applications?

AGPL was designed to cover software accessed over a network, which makes it especially important for SaaS companies to review. Whether it applies to your specific architecture depends on how you use the AGPL code, whether you modified it, and how users interact with the software. Ask a qualified lawyer before using AGPL code in a SaaS product.

2. What is the difference between GPL and LGPL?

GPL is strong copyleft and can require distributed software incorporating GPL-covered code to be released under GPL terms. LGPL is weaker copyleft and is often designed to allow linking from proprietary software under certain conditions. Modifying the LGPL library itself can still trigger sharing obligations.

3. Can I use GPL-licensed code in a commercial product?

Commercial use of GPL code is not automatically forbidden, but distribution obligations can apply. If you distribute software that incorporates GPL-covered code, you may need to make source code available under GPL terms. Consult a lawyer before using GPL code in commercial distributed software.

Software Supply Chain Security — A Complete Guide for Engineering Teams

Vulert — Fri, 31 Jul 2026 07:00:00 +0000

Software supply chain security became a board-level concern after SolarWinds, Log4Shell, XZ Utils, and public package registry attacks showed the same lesson: your application is only as trustworthy as the code, tools, maintainers, and build systems that feed it.

This guide explains what the software supply chain includes, where attacks happen, which frameworks matter, and what engineering teams should do this week, this month, and this quarter. The goal is practical protection, not a theoretical security program that never reaches CI/CD.

Note: Supply chain security is not one tool. It is dependency control, build integrity, artifact provenance, SBOM visibility, CI/CD hardening, and continuous CVE monitoring working together.

What Your Software Supply Chain Actually Is

Your software supply chain is every external and internal component that becomes part of your application or helps produce it. When a developer runs npm install, pip install, go mod download, composer install, or mvn package, the build pulls code from registries, repositories, maintainers, mirrors, plugins, and build tools. That code may become part of the final product, influence the build, or run inside CI before the product ships.

The supply chain includes direct dependencies, transitive dependencies, internal shared libraries, build tools, CI/CD actions, release scripts, package registries, artifact stores, and security tooling. A direct dependency is a package your application explicitly asks for, such as express@4.18.2, requests@2.31.0, or log4j-core@2.14.1. A transitive dependency is a package pulled in by another dependency, and those often outnumber direct dependencies by a large margin.

Engineering teams sometimes underestimate build tools. Tools such as webpack, Babel, Gradle, pytest, GitHub Actions, Jenkins plugins, npm lifecycle scripts, and release automation can run code before production deployment. If an attacker compromises a build plugin, registry account, internal package, or CI secret, the application may ship a malicious artifact even when your own source code looks clean.

Supply Chain Layer	Examples	Security Question
Direct dependencies	`express`, `django`, `spring-core`, `lodash`.	Do we know which versions we intentionally installed?
Transitive dependencies	Packages pulled in by direct dependencies.	Can we detect CVEs several layers deep?
Build tools	webpack, Babel, Gradle, pytest, Maven plugins.	Can build-time code execute with sensitive credentials?
CI/CD tools	GitHub Actions, CircleCI, Jenkins plugins, release scripts.	Can attackers modify the build or steal secrets?
Internal libraries	Private packages, shared SDKs, internal auth helpers.	Are private packages protected from dependency confusion?
SBOM and artifacts	CycloneDX, SPDX, signed releases, provenance files.	Can we prove what went into each release?

The 5 Types of Software Supply Chain Attack

Software supply chain attack is a broad phrase, but engineering teams should break it into specific attack types. A malicious npm package, a compromised maintainer account, a dependency confusion attack, a compromised build system, and long-term social engineering of a maintainer all require different defenses. Treating them as one generic risk leads to weak controls.

The common thread is trust. Modern engineering teams trust package registries, maintainers, CI workers, build scripts, release pipelines, and artifact repositories. Attackers target those trust points because they scale. One compromised package can reach thousands of downstream applications. One poisoned build system can ship malicious updates to customers. One stolen maintainer account can publish a malicious version of a package that developers already trust.

A practical supply chain security guide should therefore cover both known-vulnerability scanning and unknown malicious behavior. CVE monitoring catches packages with published vulnerabilities such as CVE-2021-44228 in Log4j or CVE-2024-3094 in XZ Utils. Registry controls and signing help detect or prevent malicious package substitution. Build provenance helps prove where an artifact came from and whether the build was tampered with.

Type 1 — Malicious Package Published to Public Registry

A malicious package attack starts when an attacker publishes a package designed to look useful, legitimate, or similar to a known package. The package may include install-time scripts, credential stealing code, data exfiltration, reverse shells, cryptominers, or payload downloaders. Developers may install it directly, or another package may pull it as a dependency.

The 2018 event-stream incident showed how a malicious dependency can enter a popular package path and reach downstream users. More recent npm and PyPI campaigns often use packages that imitate developer tooling, wallet libraries, cloud SDK helpers, or typo variants. The package may work normally enough to avoid suspicion while running hidden code during installation or import.

Type 2 — Maintainer Account Takeover

Maintainer account takeover happens when an attacker compromises a legitimate maintainer’s npm, PyPI, GitHub, or package registry account. This is more dangerous than publishing an unknown malicious package because existing users already trust the package name. The attacker can publish a new version that appears to come from the real maintainer.

Registry 2FA, trusted publishing, short-lived tokens, package signing, and release review help reduce this risk. Teams should avoid automatic major-version upgrades without review, but they also need fast patching for real security fixes. Lock files and SCA monitoring help balance speed and control.

Type 3 — Dependency Confusion

Dependency confusion exploits package resolution between private and public registries. If a company uses an internal package named auth-helper, an attacker may publish auth-helper@9.9.9 to npmjs.com. If the build system prefers the public package because it has a higher version, attacker code runs inside CI.

This attack does not require a CVE. Prevention requires scoped packages, internal registry enforcement, public namespace claiming, and lock file integrity. Read the dedicated guide here: Dependency Confusion Attacks — How They Work and How to Prevent Them.

Type 4 — Compromised Build Pipeline (SolarWinds Model)

A compromised build pipeline attack targets the process that turns source code into a release artifact. The SolarWinds incident is the classic example. SolarWinds reported that a threat actor injected code into builds of the Orion Software Platform, including SUNBURST injection into builds released between March and June 2020.

This category is hard to detect because source code review may not reveal the payload. The source can look clean while the build system inserts malicious code into the compiled artifact. Defenses include isolated build environments, reproducible builds where possible, signed provenance, restricted CI permissions, artifact signing, and strong monitoring of build infrastructure.

Type 5 — Social Engineering of Maintainers (XZ Utils Model)

Maintainer social engineering is one of the hardest supply chain risks to stop. The XZ Utils backdoor showed how an attacker can build trust over time, gain project influence, and introduce malicious changes into a widely used open source component. The backdoor was discovered after Andres Freund noticed abnormal SSH performance and investigated the cause.

XZ Utils was assigned CVE-2024-3094, and affected versions included 5.6.0 and 5.6.1 in several distributions before they were pulled or reverted. The lesson is that trust in maintainers must be paired with review, provenance, reproducible build pressure, distribution safeguards, and fast inventory answers. When the next XZ-style event happens, teams need to answer “do we use this package?” in minutes.

Supply Chain Security Frameworks — SLSA and Sigstore

Engineering teams do not need to invent a complete model from scratch. The SLSA framework and Sigstore give teams practical ways to improve build integrity and artifact trust. SLSA focuses on supply chain levels for software artifacts, especially build provenance. Sigstore focuses on signing and verifying software artifacts with a lower-friction identity-based model.

The mistake is trying to jump directly to the strictest possible controls. Most teams should start with documented builds, generated provenance, protected CI workflows, and signed artifacts. SLSA Level 2 is a realistic near-term target for many engineering teams because it moves the team from informal builds to tamper-evident build provenance. Higher levels require stronger build isolation and stricter controls that may take longer to implement.

Sigstore helps because traditional signing systems often fail on usability. Long-lived private keys are hard to manage safely. Keyless signing uses identity, short-lived certificates, and a transparency log so consumers can verify who signed an artifact and when. Sigstore’s documentation describes keyless signing and verification using certificate identity and Rekor transparency log inclusion.

SLSA — Four Levels of Supply Chain Guarantees

SLSA Level	What It Requires	Realistic For Who
SLSA 0	No specific SLSA guarantees.	Teams with ad hoc builds and no provenance.
SLSA 1	Build provenance exists and describes how the artifact was built.	Any team that can generate build metadata in CI.
SLSA 2	A hosted build platform creates provenance and gives tamper-evidence.	Most teams using GitHub Actions, GitLab CI, CircleCI, or similar platforms.
SLSA 3	The build platform prevents tampering and provides stronger isolation.	Teams with mature platform engineering and release controls.
SLSA 4	Historically associated with the strongest controls such as hermetic builds and stricter review in earlier SLSA versions.	High-assurance software producers and critical infrastructure vendors.

Sigstore — Signing Packages to Verify Provenance

Sigstore is a free and open approach for signing software artifacts such as binaries, release files, packages, SBOMs, and build outputs. It supports keyless signing, where the signer’s identity is bound through a trusted identity provider and recorded in a transparency log. This lowers the operational burden of managing long-lived signing keys.

Package ecosystems are also moving toward provenance and attestations. PyPI’s security model says attestations build on Trusted Publishing and Sigstore keyless signing, which allows packages to assert they were published by an authorized publisher from a specific CI provider and repository. npm also provides Sigstore packages for signing and verifying artifacts.

Tip: Start with build provenance for your most important release pipeline before trying to sign every internal artifact.

SBOM as the Foundation of Supply Chain Visibility

A software bill of materials is an inventory of the components inside a software product. Without an SBOM, teams struggle to answer basic incident response questions. Did we ship log4j-core@2.14.1? Did any product contain XZ Utils 5.6.0 or 5.6.1? Which customer-facing services use the affected package? Which releases need patching?

SBOMs do not stop attacks by themselves. They create visibility. That visibility becomes useful when paired with CVE monitoring, release tracking, and ownership. A CycloneDX or SPDX SBOM can be attached to a release, stored with build artifacts, scanned for CVEs, and used during customer security reviews. Teams migrating from enterprise tools can also use SBOMs as portable evidence of what each product contains.

Vulert accepts SBOM uploads in SPDX and CycloneDX formats and scans them against 458,000+ known CVEs. It also supports common manifest files such as package-lock.json, yarn.lock, pom.xml, build.gradle, requirements.txt, poetry.lock, composer.lock, go.sum, Gemfile.lock, Cargo.lock, *.csproj, and packages.lock.json. This makes SBOM and manifest scanning a practical first step for software supply chain security.

# Generate a CycloneDX SBOM with Syft
syft dir:. -o cyclonedx-json > sbom.json

# Generate SPDX JSON instead
syft dir:. -o spdx-json > sbom.spdx.json

# Then upload the SBOM to Vulert's free scanner:
# https://vulert.com/abom

If you cannot list what your software contains, you cannot quickly answer whether the next Log4Shell or XZ Utils affects you.

The Practical Supply Chain Security Checklist

The best supply chain program starts small and becomes stronger every month. Engineering teams do not need SLSA Level 4, universal signing, perfect reproducibility, and advanced behavioral malware detection on day one. They need deterministic installs, dependency monitoring, registry protection, SBOM generation, 2FA, and CI/CD controls that developers can actually maintain.

Use this checklist as a staged plan. Level 1 reduces the most common and easiest-to-fix risks this week. Level 2 adds visibility and monitoring this month. Level 3 improves build integrity, private package control, and long-term supply chain assurance this quarter. The goal is steady coverage, not a one-time audit push.

Level 1 — Start This Week

Enable dependency update automation: Turn on Dependabot or an equivalent tool for every active repository so dependency updates do not depend on manual tracking.
Commit all lock files: Commit package-lock.json, Gemfile.lock, poetry.lock, Pipfile.lock, Cargo.lock, and equivalent lock files so builds resolve deterministic versions.
Use deterministic CI installs: Replace npm install with npm ci in CI/CD because npm ci follows the lock file exactly and verifies integrity.
Enable registry 2FA: Require two-factor authentication for npm, PyPI, RubyGems, GitHub, and other package publishing accounts.
Review CI secrets: Remove unused tokens and reduce build credentials to the minimum permissions needed for each workflow.

Level 2 — Do This Month

Add continuous SCA monitoring: Use Vulert or an equivalent SCA tool so new CVEs trigger alerts when they affect package versions your applications actually use.
Generate an SBOM: Generate CycloneDX or SPDX SBOMs for your main product and store them with release artifacts.
Use scoped internal packages: Convert private npm packages from names like auth-helper to scoped names like @company/auth-helper.
Add CI security scanning: Scan dependencies, lock files, and SBOMs in CI while keeping fix ownership clear for developers.
Document package ownership: Assign owners for internal libraries so abandoned packages do not become hidden risk.

Level 3 — Plan This Quarter

Implement SLSA Level 2: Generate signed or tamper-evident build provenance from a hosted build platform for your most important release pipeline.
Create an internal package registry policy: Use allow-listing and prevent public fallback for private package names to reduce dependency confusion risk.
Reduce transitive dependency count: Review large dependency trees and remove packages that add risk without meaningful value.
Adopt artifact signing: Start signing releases, SBOMs, or critical artifacts with Sigstore-compatible workflows where practical.
Track remediation history: Keep timestamped scan history, CVE remediation records, and trend reports for engineering and audit visibility.

Common Mistakes Engineering Teams Make

Many teams treat software supply chain security as a tool purchase instead of an engineering workflow. Buying a scanner does not protect CI secrets. Signing a release does not fix vulnerable dependencies. Generating an SBOM once does not help if nobody scans it when new CVEs appear. Each control solves a specific problem, and gaps remain when teams confuse visibility with prevention.

The second mistake is focusing only on direct dependencies. Transitive dependencies often carry the hidden risk. A harmless-looking top-level package may pull dozens of libraries. When a CVE appears in a transitive dependency, developers need to know which parent package introduced it and which upgrade removes it. That is why Dependency Health grouping matters: it turns many CVEs into a smaller set of package upgrade decisions.

The third mistake is ignoring build-time code. npm postinstall scripts, CI actions, Maven plugins, and release scripts can run with more permissions than production code. If those scripts can access registry tokens, cloud credentials, signing keys, or deployment secrets, a malicious package can become a deployment incident. Lock files, registry policies, secret scoping, and CI isolation reduce that blast radius.

Warning: A clean CVE report does not prove the build pipeline is safe. CVE scanning, registry controls, build provenance, and secret management protect different failure modes.

Where Vulert Fits in a Secure Software Supply Chain

Vulert focuses on the known-vulnerability layer of a secure software supply chain. It analyzes manifest files and SBOMs against known CVEs, alerts teams when new CVEs affect their package versions, and provides fix guidance with exact versions and CLI commands. That makes it useful for the day-to-day remediation work engineering teams actually perform.

Vulert does not replace SLSA, Sigstore, private registry controls, or maintainer account protection. Those controls protect build integrity, provenance, and package origin. Vulert complements them by answering a different question: which packages in our applications have known vulnerabilities, and how do we fix them?

Teams can start with the free scanner at vulert.com/abom, upload a manifest or SBOM, and get results in 60 seconds. For ongoing coverage, continuous monitoring alerts teams when a newly disclosed CVE affects a package they already use. Dependency Health groups findings by package upgrade, Jira integration creates pre-filled tickets, and scan history gives teams remediation evidence over time. To build a stronger supply chain program, continue with these Vulert guides:

Dependency Confusion Attacks — How They Work and How to Prevent Them
How to Generate an SBOM — Tools and Commands for Every Language

These guides cover 2 practical controls from this article: preventing private package confusion and generating SBOMs that can be scanned for known CVEs.

Key Takeaways

Software supply chain security covers dependencies, transitive packages, build tools, CI/CD workflows, internal libraries, artifact signing, and SBOM visibility.
The 5 major attack types are malicious public packages, maintainer account takeover, dependency confusion, compromised build pipelines, and maintainer social engineering.
SolarWinds showed that attackers can compromise the build process, while XZ Utils showed that long-term maintainer trust can be abused.
The SLSA framework helps teams improve build provenance and tamper resistance, with SLSA Level 2 as a realistic near-term goal for many teams.
SBOMs help teams answer incident questions quickly, but they need CVE monitoring and release ownership to become useful.
Vulert fits the known-CVE layer by scanning manifests and SBOMs, providing fix commands, and continuously monitoring disclosed vulnerabilities.

Frequently Asked Questions

1. What is a software supply chain attack?

A software supply chain attack targets the code, dependencies, build systems, package registries, maintainers, or release processes that feed an application. The attacker may compromise a package, maintainer account, CI/CD pipeline, or build artifact instead of attacking the application directly.

2. How does an SBOM help with supply chain security?

An SBOM lists the components inside a software product, which helps teams answer whether they use a newly affected package. When a new CVE appears, an SBOM lets teams scan releases quickly and identify impacted products, services, and customers.

3. Is CVE scanning enough for supply chain security?

No. CVE scanning catches known vulnerable packages, but it does not fully stop dependency confusion, maintainer account takeover, build pipeline compromise, or malicious packages with no CVE. Use CVE monitoring alongside registry controls, lock files, build provenance, signing, and CI/CD hardening.

Dependency Confusion Attacks — How They Work and How to Protect Your Pipeline

Vulert — Thu, 30 Jul 2026 07:30:00 +0000

dependency confusion attack helped security researcher Alex Birsan earn $130,000 in bug bounties after demonstrating that build systems at Apple, Microsoft, PayPal, Uber, Yelp, Tesla, and 30+ other companies could be tricked into running code from public package registries.

The attack did not exploit a single CVE. It exploited a package manager assumption: when public and private registries contain packages with the same name, the build system may choose the public package, especially when the public version number is higher.

Warning: Traditional CVE scanning alone does not stop dependency confusion because the malicious package can be brand new and have no vulnerability record.

The $130,000 Bug Bounty That Changed Supply Chain Security

Dependency confusion became widely known in February 2021 when Alex Birsan showed that major companies could accidentally install attacker-controlled packages during normal builds. He did not need a zero-day exploit, leaked credentials, or malware hidden inside a popular package. He needed internal package names.

Birsan found those names through public clues. Some appeared in package.json files accidentally committed to public repositories. Others appeared in npm error messages, public documentation, or job listings that mentioned internal tooling. Once he had a private package name, he published a package with the same name to a public registry at a very high version number.

When affected build systems resolved dependencies, they sometimes chose the public package over the internal package. His packages contained logging code for proof, not destructive malware. But the result was still serious: external code executed inside internal build environments at companies with mature security teams.

Birsan earned $130,000 by reaching build systems at Apple, Microsoft, Uber, and 30+ other companies — without exploiting a single CVE.

The lesson was uncomfortable. A company could secure its code, harden its cloud, scan for known CVEs, and still lose control of the build pipeline because dependency resolution trusted the wrong registry.

How Dependency Confusion Works — The Technical Mechanism

A package manager installs dependencies from registries. For JavaScript, that might mean npm and npmjs.com. For Python, that might mean pip and PyPI. For Java, that might mean Maven and Maven Central. Many companies also run private package registries for internal libraries such as authentication helpers, design systems, API clients, logging wrappers, and shared build tools.

The confusion starts when the same package name exists in 2 places: an internal registry and a public registry. If your private package is unscoped, such as auth-helper, an attacker may publish auth-helper publicly. If the public package has a higher version number, some dependency resolution setups may install the public package instead of the internal one.

For example, your internal registry may contain auth-helper@1.0.0. An attacker publishes auth-helper@9.9.9 to the public npm registry. When your CI pipeline runs dependency installation, the package manager or registry proxy may resolve the higher public version. The build now runs attacker-controlled package code.

Internal package name leaks: The attacker finds a private package name in a public repository, error message, job listing, documentation page, or exposed build file.
Attacker publishes public package: The attacker creates a package with the same name on npm, PyPI, Maven Central, or another public registry.
Attacker chooses a high version number: The public package uses a version such as 9.9.9 so it looks newer than the internal package.
Build pipeline installs dependencies: The CI system runs npm install, pip install, or another package manager command.
Resolver chooses the public package: The package manager or registry configuration selects the attacker-controlled public package.
Malicious code executes: Install scripts, postinstall hooks, build steps, or imported code run inside the build environment.

Private Registry	Public Registry	Risk
`auth-helper@1.0.0`	`auth-helper@9.9.9`	The build may install the attacker-controlled higher public version.
`@company/auth-helper@1.0.0`	Attacker cannot publish under `@company` without scope ownership.	Scoped package naming reduces dependency confusion risk.

Real Examples of Dependency Confusion in the Wild

The original research showed the attack against major companies, but the pattern has continued because the root cause is operational, not just technical. Organizations create private packages, developers reference them in manifests, build systems connect to both private and public registries, and public clues leak internal names.

The JavaScript ecosystem remains a common discussion point because npm packages can run install-time scripts such as preinstall, install, and postinstall. If a malicious package reaches a CI worker, those scripts can run before the application even imports the package. That can expose environment variables, tokens, build metadata, hostnames, internal network details, and CI secrets if permissions are too broad.

Python and Java teams face similar registry confusion risks, although the mechanics differ. A private Python package name can conflict with PyPI. A private Java artifact can create problems if repository order and resolution rules are misconfigured. CocoaPods also had similar issues in Apple-related research because internal pod names could be mirrored publicly.

The key pattern stays the same across ecosystems: attackers look for private names, publish public lookalikes, choose high versions, and wait for a build system to install them.

Note: Dependency confusion is different from exploiting a vulnerable package version. It tricks your build into installing the wrong package entirely.

Why CVE Scanning Tools Don’t Catch This

CVE scanning checks whether known packages and versions match known vulnerability records. That workflow works well for issues such as log4j-core@2.14.1 affected by CVE-2021-44228, lodash@4.17.20 affected by prototype pollution advisories, or urllib3 versions affected by known Python package CVEs.

A dependency confusion package does not need a CVE. It may be created minutes before the attack. It may contain no known vulnerable code. It may even have a clean package name, clean version, and no public advisory. The malicious behavior comes from where it came from, what install scripts it runs, and whether it should have been installed at all.

That means SCA and CVE tools are necessary but not sufficient. They catch the known vulnerability layer. Dependency confusion prevention needs registry controls, scoped package names, lock file integrity, namespace ownership, and behavioral detection for suspicious package actions.

SCA tools: These tools detect known CVEs in packages you intentionally installed.
Registry controls: These controls stop private package names from resolving to public registries.
Behavioral analysis: These tools can flag unusual install scripts, network calls, credential access, or suspicious package behavior.
Lock file integrity: This prevents package content from changing without hash mismatch detection.

Vulert fits the CVE layer. It monitors manifest files and SBOMs against 458,000+ known CVEs, provides exact fixed versions, and gives CLI commands for known vulnerable dependencies. It does not replace registry hardening for dependency confusion, and that distinction matters.

4 Ways to Prevent Dependency Confusion Attacks

The best dependency confusion prevention strategy uses multiple controls. Do not rely on a single package manager setting. Use scoped names, registry rules, lock file integrity, and namespace ownership together. That way, one missed setting does not expose the entire build pipeline.

Start with internal package naming. Then lock registry resolution. Then enforce deterministic builds with lock files. Finally, claim public namespaces and package names before attackers do. These steps work because they remove ambiguity from dependency resolution.

1. Use Scoped Packages for All Internal Code

Scoped packages add a namespace to package names. In npm, @yourcompany/auth-helper belongs to the @yourcompany scope. An attacker cannot publish under that scope unless they control it. This makes scoped packages safer than unscoped internal names such as auth-helper.

{
  "name": "@yourcompany/auth-helper",
  "version": "1.0.0"
}

Claim your company scope immediately on public registries where your developers publish or install packages. Even if you do not publish public packages, owning the namespace prevents outsiders from taking it first.

2. Configure Your Package Manager to Use Internal Registry Only

Registry configuration decides where package managers look for packages. If your internal packages should only come from an internal registry, configure the package manager to enforce that rule. Do not allow public registry fallback for private package names.

# .npmrc at project root
@yourcompany:registry=https://your-internal-registry.com
registry=https://your-internal-registry.com

This setup forces npm to use your internal registry. Your internal registry can then proxy public packages through a controlled path with allowlists, access rules, and caching. That gives the organization one place to enforce package policy.

3. Always Use Lock File Integrity Checking

Lock file integrity pins exact package versions and package hashes. A package-lock.json file records not only which version should install, but also the expected integrity hash. If an attacker’s package has different content, the hash check can fail.

# Use deterministic installs in CI
npm ci

# Avoid this in production pipelines
npm install

Use npm ci in CI and production build pipelines. It installs exactly what the lock file declares and fails when the lock file and manifest do not match. This reduces surprise dependency changes during builds.

4. Claim Your Namespace on Public Registries

Namespace claiming prevents attackers from registering names that belong to your company. If your internal package is named internal-auth, consider publishing a placeholder package with that name to public registries where confusion could occur. Set the version to 0.0.0 and clearly mark it as an internal placeholder with no public release.

This is not a complete defense, but it reduces name takeover risk. It works best alongside scoped package naming and strict registry configuration. Treat namespace claiming as a safety net, not the primary control.

Tip: Audit all internal package names before attackers do. Search manifests, build logs, CI configs, and public repositories for private package names.

Dependency Confusion vs Typosquatting — Understanding Both Threats

Typosquatting and dependency confusion both abuse package ecosystems, but they work differently. A typosquatting attack tricks developers into installing the wrong package by using a name that looks similar to a popular package. For example, an attacker may publish lodahs to catch developers who meant to install lodash.

A dependency confusion attack does not need a typo. It uses the exact private package name. The attacker publishes that name publicly, often with a higher version number, and waits for the build system to resolve the public package instead of the private one.

The defenses overlap but are not identical. Typosquatting prevention needs package review, trusted package policies, behavioral detection, and developer caution. Dependency confusion prevention needs private namespace control, scoped packages, registry configuration, and lock file integrity.

Attack Type	How It Works	Example	Main Defense
Dependency confusion	Attacker publishes a public package with the same name as a private package.	`auth-helper@9.9.9` beats internal `auth-helper@1.0.0`.	Use scoped packages and block public fallback.
Typosquatting	Attacker publishes a package name similar to a popular package.	`lodahs` imitates `lodash`.	Review packages and enforce trusted sources.
Known CVE dependency risk	A legitimate dependency version has a published vulnerability.	`log4j-core@2.14.1` is affected by `CVE-2021-44228`.	Use SCA monitoring and upgrade to fixed versions.

How Dependency Confusion Relates to Continuous Monitoring

A dependency confusion attack uses trust and resolution mistakes. Known CVE monitoring uses vulnerability intelligence. Both are supply chain security controls, but they catch different failure modes.

Registry controls stop the build from installing the wrong package. Behavioral tools can flag suspicious install scripts or unexpected network activity. Lock files make builds deterministic. SCA tools monitor the packages you knowingly installed and alert when new CVEs affect them later.

Vulert helps with the known CVE layer. It analyzes manifest files and SBOMs, alerts teams when new CVEs affect specific package versions, provides exact fixed versions, and includes CLI commands developers can run. It supports package-lock.json, yarn.lock, pom.xml, build.gradle, requirements.txt, Pipfile.lock, poetry.lock, composer.lock, go.sum, Gemfile.lock, Cargo.lock, pubspec.lock, mix.lock, *.csproj, packages.lock.json, and SBOM files in SPDX and CycloneDX formats.

The correct strategy is not “SCA or dependency confusion controls.” It is both. Use registry hardening to stop malicious package substitution, and use Vulert or another SCA tool to catch known CVEs in the dependency tree you actually intended to install.

Build Pipeline Checklist for Dependency Confusion Prevention

Security teams should turn dependency confusion prevention into a build pipeline checklist. The goal is to remove ambiguity from every package install. A CI worker should know exactly which registry to use, which package version to install, which hash to verify, and which package names are allowed.

Start with npm because JavaScript builds often use install scripts and large transitive dependency trees. Then repeat the same pattern for Python, Maven, NuGet, RubyGems, Go modules, and other ecosystems. Each package manager has different controls, but the principle stays the same: private names should never silently fall through to public registries.

Inventory private package names: List every internal package name across manifests, lock files, monorepos, CI configs, and private registries.
Convert unscoped npm packages: Move internal packages from names like auth-helper to scoped names like @yourcompany/auth-helper.
Claim public scopes and names: Register company namespaces and defensive placeholder packages on public registries where needed.
Lock registry resolution: Configure package managers to use internal registries for private packages and prevent public fallback.
Use deterministic installs: Run npm ci in CI and enforce lock file integrity for production builds.
Monitor install-time behavior: Watch for suspicious postinstall scripts, unexpected network calls, credential access, or external callbacks during builds.
Scan known CVEs separately: Use Vulert or another SCA tool to monitor legitimate dependencies for published vulnerabilities.

Key Takeaways

A dependency confusion attack tricks package managers into installing a malicious public package instead of a private internal package.
Alex Birsan’s 2021 research showed that major companies could be reached through package resolution mistakes without exploiting a single CVE.
Unscoped internal package names such as auth-helper create more risk than scoped names such as @company/auth-helper.
Traditional CVE scanning does not catch brand-new malicious packages because they may have no advisory, no CVE, and no known vulnerability record.
Prevention requires scoped packages, strict registry configuration, lock file integrity, namespace claiming, and behavioral monitoring.
SCA tools such as Vulert complement dependency confusion defenses by monitoring known CVEs in the packages you intentionally installed.

Frequently Asked Questions

1. What is a dependency confusion attack?

A dependency confusion attack happens when an attacker publishes a public package with the same name as a private internal package. If the build system chooses the public package, attacker-controlled code can run inside the development or CI environment.

2. Does npm audit detect dependency confusion attacks?

npm audit checks known vulnerabilities in installed packages. It does not reliably detect dependency confusion because the malicious package may be brand new and have no CVE or advisory. Registry controls and scoped packages are the primary defenses.

3. Can SCA tools prevent dependency confusion?

SCA tools help with known CVEs, but they do not replace registry hardening. Use SCA for vulnerable packages you intentionally installed, and use scoped names, internal registry rules, and lock file integrity to prevent dependency confusion.

Wiz vs Traditional SCA Tools — Cloud Security vs Dependency Security

Vulert — Thu, 30 Jul 2026 07:00:00 +0000

A team can pass a cloud security review in Wiz and still ship a Node.js service with 47 vulnerable npm packages. That is why teams searching for a Wiz security alternative should first separate 2 layers: cloud infrastructure security and application dependency security.

Wiz is built for cloud-native security across infrastructure, identities, workloads, exposure, and misconfigurations. Traditional software composition analysis tools scan application dependency files such as package-lock.json, pom.xml, requirements.txt, and SBOMs. This guide explains what Wiz does well, what SCA tools do differently, who needs both, and where a focused tool like Vulert fits.

What Wiz Does — Cloud Infrastructure Security

Wiz is a Cloud Native Application Protection Platform, usually shortened to CNAPP. A CNAPP helps teams understand risk across cloud environments such as AWS, Azure, GCP, OCI, Kubernetes, and private cloud infrastructure. Wiz focuses on cloud visibility, attack paths, misconfigurations, workload exposure, cloud vulnerabilities, identity risks, IaC issues, data exposure, and runtime context.

Wiz is excellent at answering cloud-layer questions. Are any S3 buckets public? Which workloads are internet-exposed? Which identities have too much privilege? Which cloud resources sit on a risky attack path? Which VM or container workload has an operating-system package vulnerability and public exposure? Which Terraform or Kubernetes configuration creates cloud risk before deployment?

That cloud graph view is valuable because cloud risk is often contextual. A vulnerable package on an isolated internal workload does not carry the same risk as the same vulnerability on an internet-facing workload with access to sensitive data and over-permissive identity permissions. Wiz is designed to connect those dots across infrastructure and prioritize cloud risks by exposure and blast radius.

Wiz Capability	What It Answers	Example Finding
Cloud misconfiguration management	Is the cloud environment configured securely?	An object storage bucket allows public read access.
Cloud workload vulnerability management	Which running workloads have vulnerable OS or runtime components?	A Linux VM runs a vulnerable OpenSSL package.
Network exposure analysis	Which services are reachable from the internet?	A database port is reachable through a risky security group.
Identity risk analysis	Which users, roles, and service accounts have excessive access?	A workload identity can read sensitive storage it does not need.
IaC security	Which infrastructure code changes create cloud risk?	A Terraform change creates an overly permissive firewall rule.
Runtime and threat context	Which cloud risks are active, exposed, or part of an attack path?	A vulnerable workload is internet-facing and has access to secrets.

What Wiz Does Not Do — The Application Dependency Layer

Wiz has a strong cloud security story, and it also discusses application security, SCA, SBOMs, and code-to-cloud context. But teams should not confuse cloud workload visibility with deep application dependency monitoring from manifest and lock files. A dedicated SCA workflow starts from the application’s declared dependency tree and continuously maps package names and exact versions to known CVEs.

That distinction matters. A Node.js application may run inside a well-configured cloud environment. Its VM may have no public SSH, its container may not run as root, its IAM role may be minimal, and its network path may be private. Wiz may show low cloud risk. But the application can still include vulnerable packages such as lodash@4.17.20, axios@0.21.1, minimist@0.0.8, jackson-databind@2.9.9, or log4j-core@2.14.1.

Traditional SCA tools focus on those package versions. They read files such as package-lock.json, pom.xml, requirements.txt, poetry.lock, composer.lock, go.sum, Cargo.lock, and SBOMs. Then they identify CVEs, fixed versions, upgrade paths, and remediation commands. This is the application dependency layer, and it needs its own monitoring workflow.

Application manifest scanning: A dedicated SCA tool reads declared dependency files and lock files to identify vulnerable npm, Maven, pip, Composer, Go, Rust, Ruby, Dart, Elixir, and .NET packages.
Fix-command guidance: A dedicated SCA tool can tell a developer the exact package version and command needed to upgrade a vulnerable dependency.
SBOM upload: A dedicated SCA tool can analyze CycloneDX or SPDX SBOMs and map listed components to known CVEs.
Dependency grouping: A focused SCA workflow can group hundreds of CVEs into the package upgrades that remove the most risk.

Warning: A clean cloud posture result does not prove clean application dependencies. Cloud security and dependency security measure different layers.

What SCA Tools Do That Wiz Does Not

Software composition analysis tools answer a specific question: which declared open source dependencies in this application have known vulnerabilities? Vulert, Snyk, Mend, and similar tools scan manifest files, lock files, and SBOMs to identify vulnerable packages and versions. This is different from scanning the runtime cloud asset from the outside.

A focused SCA tool like Vulert analyzes manifest files and SBOMs against 458,000+ known CVEs. It supports files such as package-lock.json, yarn.lock, pom.xml, build.gradle, requirements.txt, Pipfile.lock, poetry.lock, composer.lock, go.sum, Gemfile.lock, Cargo.lock, pubspec.lock, mix.lock, *.csproj, packages.lock.json, and CycloneDX or SPDX SBOMs.

The output is developer-actionable. Instead of only saying “this workload has vulnerabilities,” Vulert can show which package is affected, which version is installed, which fixed version resolves the CVE, and what command to run. Its Dependency Health view groups CVEs by package upgrade, so a team can avoid opening 47 separate tickets when 3 package upgrades remove most of the risk.

# Example: generate an SBOM from an application directory
syft dir:. -o cyclonedx-json > sbom.json

# Example files you can upload to an SCA scanner
# package-lock.json
# pom.xml
# requirements.txt
# composer.lock
# go.sum
# Cargo.lock
# sbom.json

This is why “Wiz dependency scanning” can mean different things in vendor conversations. Wiz can surface vulnerability context in workloads and cloud environments. Dedicated SCA tools focus directly on the application dependency tree from manifests and SBOMs. The safer architecture is to use both layers where both risks exist.

The Key Distinction — Infrastructure vs Application Dependencies

The core difference is simple: Wiz looks at cloud infrastructure and running workload context; SCA looks at application dependency declarations. Wiz tells you whether your cloud environment is configured securely. SCA tells you whether the packages your developers included in the application have known CVEs.

Think of the system as 2 layers. The bottom layer is cloud infrastructure: accounts, networks, IAM, storage, compute, containers, Kubernetes, exposed services, and runtime workloads. Wiz is designed for this layer. The top layer is application dependency security: npm packages, Maven JARs, PyPI packages, Composer packages, Go modules, Rust crates, Ruby gems, and SBOM components. Vulert and other SCA tools are designed for this layer.

A cloud scanner may see that a container is running and whether the workload is exposed. It may see OS-level packages or workload vulnerabilities. But a dedicated SCA tool reads the developer’s source-level dependency files and lock files. That is where it finds exact declared dependencies, transitive packages, and application-level CVE matches before the app even deploys.

Layer	Primary Question	Best Tool Type	Example
Cloud infrastructure	Is the environment exposed, misconfigured, or over-permissioned?	CNAPP such as Wiz.	An internet-facing VM has a risky IAM role and access to sensitive data.
Running workload	Which deployed assets carry contextual runtime risk?	CNAPP and workload vulnerability tools.	A running container has a vulnerable OS package and public exposure.
Application dependency tree	Which declared packages and versions have known CVEs?	SCA tools such as Vulert, Snyk, or Mend.	`log4j-core@2.14.1` is affected by `CVE-2021-44228`.
SBOM and release evidence	Which components exist in this application release?	SCA and SBOM scanners.	A CycloneDX SBOM lists vulnerable transitive dependencies.

Wiz answers “is our cloud environment risky?” SCA answers “are our application dependencies vulnerable?” Both questions matter, but they are not the same question.

A Concrete Example — Same App, Different Scanners, Different Findings

Imagine a Node.js application running behind a private load balancer in AWS. The S3 buckets are private. IAM permissions follow least privilege. No public database port exists. The security groups are tight. The container does not run as root. Wiz reviews the cloud environment and shows no urgent cloud misconfiguration. That is a good result.

Now scan the application’s package-lock.json with an SCA tool. The report finds 47 CVEs across packages such as lodash, axios, follow-redirects, semver, and tough-cookie. One package has a fixed version available. Another package needs a transitive dependency update through a parent package. A third finding has no patch yet and needs a workaround. The cloud layer was clean. The dependency layer was not.

This is not a contradiction. It means the scanners looked at different evidence. Wiz inspected infrastructure and workload context. The SCA scanner inspected the declared dependency graph. Both results can be true at the same time.

Cloud scan result: Wiz shows no public storage, no dangerous IAM path, and no exposed database, so the infrastructure risk is low.
SCA scan result: Vulert shows 47 application dependency CVEs in package-lock.json, so the application dependency risk is high.
Developer action: The engineering team upgrades 3 packages and reduces most of the CVE count.
Security action: The platform team keeps the cloud controls in place while AppSec monitors future dependency disclosures.

Tip: Use cloud security findings to protect the environment and SCA findings to fix the code dependency tree. Do not force one tool to replace the other layer.

Who Needs Wiz, Who Needs SCA, Who Needs Both

The right tool choice depends on what your team operates. Teams that manage multi-cloud infrastructure, Kubernetes clusters, sensitive cloud data, broad IAM roles, and internet-facing workloads need a CNAPP such as Wiz. Teams that build applications with open source packages need SCA. Many software companies need both because they operate cloud infrastructure and ship code with dependencies.

A team running applications on Heroku, Railway, Render, Vercel, or another managed platform may not need a full CNAPP at the beginning. The cloud provider or platform abstracts much of the infrastructure configuration. But the application still includes npm, Maven, pip, Composer, Go, Rust, Ruby, Dart, Elixir, and .NET dependencies. That team still needs SCA.

Early-stage and mid-size teams should usually start with SCA because dependency CVEs are easy to introduce, easy to miss, and often fixable with package upgrades. Cloud security becomes more urgent as the team manages more direct cloud infrastructure, data stores, networks, identities, and Kubernetes resources.

Team Situation	Needs Wiz?	Needs SCA?	Reason
Startup on Heroku or Render with 3 web apps.	Usually no.	Yes.	The platform manages most cloud configuration, but the code still uses vulnerable packages.
SaaS company on AWS with Kubernetes and sensitive customer data.	Yes.	Yes.	The team owns cloud exposure, IAM, workloads, and application dependencies.
Enterprise with multi-cloud accounts and many business units.	Yes.	Yes.	Cloud posture and dependency vulnerability monitoring both need central governance.
Agency managing WordPress and Node.js projects for clients.	Maybe.	Yes.	Dependency and CMS package risk is immediate, while CNAPP depends on who owns cloud infrastructure.
Internal tool team with no direct cloud ownership.	Usually no.	Yes.	The team still ships dependencies even if infrastructure is managed elsewhere.

Cost and Sequencing — Where to Start

Wiz and Vulert also sit in very different cost categories. Wiz is an enterprise cloud security platform, and public pricing estimates vary widely by cloud footprint, modules, workload count, contract size, and negotiation. Third-party pricing analysis commonly places Wiz-style CNAPP deals in the tens of thousands to hundreds of thousands of dollars per year for many organizations, while Vulert Pro is $45 per month, or $540 per year. Because pricing can vary, teams should confirm current vendor quotes before buying.

The budget difference reflects the product difference. Wiz maps and prioritizes risk across cloud infrastructure. Vulert monitors application dependencies. These are not competing products at the same price point. They solve different problems for different parts of the stack.

Sequencing should follow ownership. If your team directly manages AWS, Azure, GCP, Kubernetes, and sensitive cloud data, evaluate Wiz or another CNAPP. If your team ships application code with third-party packages, start SCA immediately. For most 10-200 person companies, SCA is the fastest first step because it requires no cloud integration and produces developer-actionable fixes within minutes.

Tool Type	Primary Layer	Typical Buying Motion	Example Cost Context
Wiz / CNAPP	Cloud infrastructure, workloads, IAM, exposure, cloud graph.	Enterprise evaluation, cloud access review, security platform rollout.	Often quoted in tens of thousands to 100,000+ dollars per year depending on footprint.
Vulert / SCA	Application dependency manifests and SBOMs.	Upload manifest, scan SBOM, add monitoring, create tickets.	Pro plan is $45 per month, or $540 per year.
Both together	Cloud posture plus dependency CVEs.	Security team owns CNAPP, engineering owns SCA remediation.	Best fit for teams that operate cloud infrastructure and build applications.

When Wiz Is the Right Tool

Wiz is the right tool when the main risk lives in cloud infrastructure. If your team owns multiple cloud accounts, Kubernetes clusters, workloads, IAM roles, storage buckets, databases, network routes, secrets, and exposed services, you need cloud-native security visibility. A spreadsheet or basic cloud console review will not scale.

Wiz can help security teams connect cloud risk signals. For example, a vulnerable workload is more urgent if it is internet-facing, has access to sensitive data, and runs with a powerful identity. A misconfigured storage bucket is more urgent if it contains regulated customer data. An over-permissive IAM role is more urgent if it sits on a path from a public workload to a production database.

That context is where a CNAPP shines. It helps cloud security and platform teams prioritize the small set of cloud risks that matter most. It does not remove the need for dependency scanning, but it solves a real and separate cloud security problem.

When SCA Is the Right First Tool

SCA is the right first tool when your main immediate risk is open source dependencies. Most application teams use hundreds or thousands of third-party packages. A single vulnerable transitive dependency can hide several layers deep. Developers may not know that a package such as jackson-databind, log4j-core, urllib3, requests, lodash, or minimist exists in the project until a scanner identifies it.

Vulert is built for this workflow. Upload a manifest or SBOM, get a vulnerability report in 60 seconds, review affected packages, and apply exact fix commands. Then turn on continuous monitoring so the team gets alerted when new CVEs affect the package versions already in use.

This is why teams often start with SCA before buying a CNAPP. SCA requires less setup, less procurement, and less architecture review. It gives engineering teams immediate visibility into dependency CVEs and often produces quick wins through package upgrades.

Tip: If your team can only fund one tool this quarter and you ship application code, start with SCA. Add CNAPP when cloud infrastructure ownership and exposure justify the platform cost.

Key Takeaways

Wiz is a CNAPP focused on cloud infrastructure, workload context, network exposure, IAM risk, misconfiguration management, and cloud attack paths.
SCA tools such as Vulert focus on declared application dependencies in manifest files, lock files, and SBOMs.
A clean Wiz cloud scan does not prove clean application dependencies because the scanners inspect different layers.
Teams that operate cloud infrastructure and build applications usually need both Wiz and SCA, not one replacing the other.
Teams on managed platforms with little direct cloud ownership may need SCA first and CNAPP later.
Vulert Pro costs $45 per month and provides manifest/SBOM scanning, continuous CVE monitoring, exact fixed versions, CLI commands, and Dependency Health grouping.

Frequently Asked Questions

1. Does Wiz scan npm or Maven dependencies?

Wiz has application security and SCA-related capabilities in its broader platform story, but teams should not assume it replaces a dedicated manifest-first SCA workflow. A tool like Vulert directly scans files such as package-lock.json, pom.xml, requirements.txt, and SBOMs for package-level CVEs and fix guidance.

2. What is the difference between CNAPP and SCA?

A CNAPP secures cloud environments, workloads, identities, network exposure, misconfigurations, and cloud attack paths. SCA scans application dependency trees for vulnerable open source packages. CNAPP looks at cloud infrastructure risk, while SCA looks at package and version risk in your application.

3. Can Wiz replace Snyk or Vulert?

Wiz should not be treated as a direct replacement for Snyk or Vulert when the requirement is dedicated application dependency scanning from manifests and SBOMs. Wiz is strongest for cloud security context, while Vulert is focused on SCA vulnerability monitoring and developer fix guidance.

Checkmarx Alternative — SCA and SAST for Mid-Size Teams

Vulert — Wed, 29 Jul 2026 07:30:00 +0000

A 75-person engineering team can end up paying for an enterprise application security platform when the team mostly needs 2 things: reliable software composition analysis for open source CVEs and practical static application security testing for custom code. That is where the search for a Checkmarx alternative usually starts.

Checkmarx is a strong enterprise product. The question is not whether Checkmarx works. The question is whether a mid-size team needs the full platform, the implementation overhead, and a $50,000-$200,000 annual security budget when smaller tools can cover the capabilities they actually use.

What Checkmarx Actually Covers

Checkmarx is an enterprise application security platform. It is not just one scanner. Checkmarx One brings multiple AppSec capabilities into a single platform, including SAST, SCA, IaC Security, API Security, secrets detection, and supply chain security features. That broad coverage is useful for large enterprises with mature AppSec teams, central security operations, many business units, and formal governance requirements.

The most recognized capability is CxSAST, which analyzes custom source code for vulnerabilities such as SQL injection, cross-site scripting, insecure deserialization, buffer overflow patterns, and unsafe input handling. CxSCA focuses on open source dependency vulnerabilities. That means it looks at third-party packages and flags known CVEs affecting versions in use. Checkmarx also offers API security, IaC scanning, and supply chain security features for teams that want a broader AppSec platform.

For large organizations, that all-in-one model can make sense. A central team gets one vendor, one reporting layer, one procurement relationship, and one place to manage different AppSec signals. For a mid-size team, the same model can feel heavy. Teams often use only SCA and SAST daily, while paying for a platform priced for organizations with much larger security teams.

Checkmarx Capability	What It Does	Coverage Quality	Mid-Size Team Replacement
CxSAST	Scans custom source code for vulnerabilities such as SQL injection and XSS.	Strong enterprise SAST coverage.	Semgrep OSS, SonarQube Community, Snyk Code, or SonarCloud.
CxSCA	Scans open source dependencies for known CVEs.	Strong enterprise SCA capability.	Vulert for manifest and SBOM-based vulnerability monitoring.
API Security	Tests and identifies API security weaknesses.	Useful for mature API programs.	OWASP ZAP for free DAST and API testing workflows.
IaC Security	Scans Terraform, Kubernetes, and cloud configuration code.	Useful for cloud and platform teams.	Checkov for Terraform, Kubernetes, and IaC scanning.
Supply Chain Security	Helps detect dependency and build pipeline risks.	Useful at enterprise scale.	SBOM generation, Vulert monitoring, CI checks, and release controls.

Why Teams Look for Checkmarx Alternatives

Teams usually look for a checkmarx alternative for 4 reasons: price, divestiture, unused platform breadth, and implementation overhead. Checkmarx is built for enterprise application security programs. That is a strength for large companies, but it can make the product feel misaligned for a smaller engineering organization that needs fast coverage and practical remediation.

The first reason is cost. A mid-size company may not have a dedicated AppSec budget large enough for a $50,000-$200,000 annual platform. The second reason is post-divestiture loss of access. A business unit may separate from a parent company and suddenly lose shared Checkmarx licenses, enterprise SSO, central scanning pipelines, and reporting history. The third reason is over-featured buying. Many teams primarily use CxSCA for dependency CVEs, but the contract covers a broader AppSec suite. The fourth reason is setup effort. Enterprise tools often need integration work, rule tuning, onboarding, triage workflows, and security ownership that small teams do not have.

A replacement stack does not need to copy every enterprise feature on day 1. It needs to restore coverage for the highest-risk workflows: custom code scanning, dependency vulnerability monitoring, IaC checks, and basic API testing. Once those are covered, the team can decide whether it needs more advanced platform features later.

The right question is not “Which tool has the longest feature list?” The right question is “Which stack covers the risks we actually fix every week?”

Replacing Each Checkmarx Capability

The practical way to replace Checkmarx is to split the platform into capabilities. Do not start by searching for one giant replacement. Start with what the team used: CxSAST, CxSCA, IaC scanning, API testing, and reporting. Then choose the smallest reliable tool for each job.

This approach works especially well for mid-size teams because it avoids a second enterprise procurement cycle. A team can run Semgrep for SAST, Vulert for SCA, Checkov for IaC, and OWASP ZAP for API or DAST workflows. Add an annual boutique penetration test for independent validation, and the total program can still cost far less than a full enterprise platform.

This model does require ownership. Someone must decide which findings block releases, which findings create backlog tickets, and which reports get reviewed each sprint. The advantage is speed. A team can start scanning code and dependencies in under an hour instead of waiting through contract reviews, implementation calls, and platform onboarding.

Replacing CxSAST — Static Code Analysis

Static application security testing scans your own source code before it runs. It finds insecure coding patterns such as SQL injection, cross-site scripting, command injection, path traversal, insecure deserialization, unsafe cryptography, and authentication mistakes. Checkmarx CxSAST is strong in this category, but not every team needs an enterprise SAST platform to get useful coverage.

The best free starting point is Semgrep. Semgrep has community rules, strong language coverage, and a simple developer workflow. It works well for teams that want fast local scans, CI checks, and readable rules. For teams with strong Java or JavaScript needs, SonarQube Community Edition can also help with maintainability and security-related code issues. Paid tools below typical enterprise pricing include Snyk Code and SonarCloud.

# Install Semgrep with pip
python3 -m pip install semgrep

# Run Semgrep with automatic rule selection
semgrep --config=auto .

# Alternative syntax used in many CI examples
semgrep scan --config auto .

Use Semgrep first for fast developer feedback. Add custom rules later for business-specific patterns such as unsafe tenant checks, direct object access, missing authorization middleware, or prohibited crypto libraries. For a 10-200 person team, this often provides enough SAST coverage to replace day-to-day Checkmarx code scanning.

Replacing CxSCA — Dependency Vulnerability Scanning

Software composition analysis scans open source dependencies for known CVEs. This is the Checkmarx capability many mid-size teams use most often because dependency vulnerabilities appear constantly and require ongoing monitoring. When teams compare Checkmarx SCA to a smaller replacement, the cost difference can be dramatic.

Vulert is the best replacement for teams that need SCA coverage without the full enterprise platform. Vulert analyzes manifest files and SBOMs against 458,000+ known CVEs. It supports package-lock.json, yarn.lock, pom.xml, build.gradle, requirements.txt, Pipfile.lock, poetry.lock, composer.lock, go.sum, Gemfile.lock, Cargo.lock, pubspec.lock, mix.lock, *.csproj, packages.lock.json, and SBOM files in SPDX and CycloneDX formats.

This matters for teams migrating away from Checkmarx because SBOM portability reduces migration pain. If the team already exports CycloneDX or SPDX SBOMs, it can upload those files directly to vulert.com/abom and continue vulnerability analysis. Vulert also gives exact fixed versions and CLI commands, so developers get “upgrade to this version with this command,” not only “this package has a CVE.”

# Example: generate an SBOM with Syft, then upload it to Vulert
syft dir:. -o cyclonedx-json > sbom.json

# Or scan the original manifest directly with Vulert's free scanner:
# package-lock.json, pom.xml, requirements.txt, composer.lock, go.sum, Cargo.lock, or SBOM

Tip: Start SCA migration first. New CVEs are disclosed daily, so dependency monitoring is the capability you should restore fastest after losing Checkmarx access.

Replacing IaC Security

Infrastructure as code security scans Terraform, Kubernetes, CloudFormation, Helm charts, and other configuration files before they create risky cloud resources. Checkmarx includes IaC security in its platform, but smaller teams can get strong free coverage with Checkov.

Checkov is a widely used IaC scanner from Bridgecrew/Palo Alto Networks. It works well for Terraform and Kubernetes misconfiguration checks, including public storage buckets, overly broad security groups, missing encryption, weak IAM permissions, and risky Kubernetes workload settings. For teams using Terraform heavily, Checkov is usually the fastest replacement for enterprise IaC scanning.

# Install Checkov
pip install checkov

# Scan a Terraform or IaC directory
checkov -d /path/to/terraform/code

# Scan the current directory
checkov -d .

# Optional: scan only Terraform
checkov -d . --framework terraform

Run Checkov in CI for pull requests that change infrastructure code. Do not block every finding on day 1. Start by blocking obvious high-risk patterns such as public database exposure, public object storage, missing encryption, and broad administrative permissions. Then tune policies by cloud provider and environment.

Replacing API Security

API security testing checks whether APIs expose unsafe endpoints, weak authentication, broken access control, injection paths, and risky behaviors. Checkmarx offers API security capability inside its broader platform, but many mid-size teams can start with OWASP ZAP for free DAST and API testing workflows.

OWASP ZAP is mature, free, widely used, and suitable for baseline web and API testing. It works best when teams provide API definitions, test environments, authentication flows, and realistic test accounts. It is not a perfect replacement for every enterprise API security workflow, but it gives mid-size teams a practical starting point without enterprise pricing.

Use ZAP against staging environments first. Add it to CI for baseline scans, then schedule deeper scans outside the critical deployment path. Pair ZAP with manual testing for sensitive authorization logic because automated API scanners often miss business-specific access control flaws.

# Example OWASP ZAP baseline scan using Docker
docker run -t ghcr.io/zaproxy/zaproxy:stable zap-baseline.py \
  -t https://staging.example.com \
  -r zap-report.html

The Full Cost Comparison

The strongest argument for a checkmarx alternative is not that Checkmarx is bad. It is that many teams can cover their practical risk at a much lower annual cost. A realistic replacement stack for a mid-size company might use Semgrep OSS for SAST, Vulert Pro for SCA, Checkov for IaC, OWASP ZAP for API or DAST testing, and one annual boutique penetration test for independent validation.

This stack does not produce the same single-vendor enterprise platform experience. It also does not include every advanced feature an enterprise AppSec organization may want. But it does restore the core workflows that engineering teams need: scan custom code, scan dependencies, scan infrastructure code, test APIs, create tickets, and prove remediation progress.

The difference becomes clear when cost enters the discussion. Checkmarx full platform pricing often fits enterprise budgets. A smaller stack can fit mid-size budgets while still giving security and engineering teams meaningful coverage.

Option	Capabilities Covered	Estimated Annual Cost	Best Fit
Checkmarx full platform	SAST, SCA, API security, IaC security, supply chain security, reporting.	$50,000-$200,000+ per year.	Large enterprises with centralized AppSec teams.
Semgrep OSS	SAST for custom code.	$0.	Developer-first code scanning.
Vulert Pro	SCA dependency vulnerability monitoring.	$540 per year.	Teams replacing CxSCA quickly.
Checkov	IaC scanning for Terraform, Kubernetes, and cloud config.	$0.	Cloud and platform teams using IaC.
OWASP ZAP	API and DAST baseline testing.	$0.	Staging scans and basic API security testing.
Annual boutique pen test	Manual validation and business logic testing.	$8,000-$15,000 per year.	Independent assurance for customers and leadership.
Replacement stack total	SAST, SCA, IaC, API testing, annual manual review.	$9,000-$16,000 per year.	Mid-size teams that need coverage without enterprise pricing.

Checkmarx vs Snyk vs Open Source Stack

The Checkmarx vs Snyk comparison often comes up because both vendors sell application security capabilities, while open source tools cover pieces of the same workflow. Checkmarx is broader as an enterprise platform. Snyk is developer-friendly and strong across dependency security, code scanning, containers, and IaC in its own platform model. Open source tools give more control and lower cost but require more assembly and ownership.

For a mid-size team, the best answer depends on the security function you need most. If the team wants one commercial developer security platform and has budget, Snyk may be easier to adopt than a heavier enterprise platform. If the team mainly needs to replace Checkmarx SCA, Vulert is a more focused and lower-cost option. If the team needs basic SAST and IaC coverage quickly, Semgrep and Checkov can start producing results the same day.

The open source stack works best when engineering owns remediation and wants fast feedback. It works less well when leadership demands one dashboard for every AppSec signal, enterprise workflow customization, and centralized policy enforcement across hundreds of teams. In that case, Checkmarx or another enterprise platform may still be the right fit.

For Post-Divestiture Teams — Getting Covered in Under an Hour

Post-divestiture teams have a different problem from normal tool evaluation. They may lose Checkmarx access suddenly because licenses, SSO, CI integrations, security dashboards, and historical reports belonged to the parent company. In that situation, the goal is not a perfect AppSec architecture. The goal is coverage today.

Start with SCA because new CVEs are disclosed every day. Vulert can scan a manifest or SBOM in 60 seconds through vulert.com/abom. A team can upload package-lock.json, pom.xml, requirements.txt, composer.lock, go.sum, Cargo.lock, packages.lock.json, or CycloneDX/SPDX SBOMs and get a vulnerability report quickly. Then the team can add continuous monitoring to avoid missing future CVEs.

Next, run Semgrep locally or in CI. The first scan does not need perfect rule tuning. It needs to show whether obvious code issues exist. Then add Checkov for Terraform and Kubernetes changes. Finally, schedule OWASP ZAP baseline scans for staging systems and plan a boutique penetration test when the team has budget.

First 5 minutes: Upload your manifest file or SBOM to Vulert and restore dependency vulnerability visibility.
Next 10 minutes: Install Semgrep and scan the repository with automatic rules.
Next 10 minutes: Run Checkov against Terraform, Kubernetes, or cloud configuration directories.
Next 15 minutes: Run OWASP ZAP baseline scan against staging if a safe staging URL exists.
Final 20 minutes: Create Jira tickets for Critical and High findings and assign owners.

# 0-60 minute post-divestiture replacement workflow

# SAST: scan custom code
python3 -m pip install semgrep
semgrep --config=auto .

# IaC: scan infrastructure code
pip install checkov
checkov -d .

# API/DAST: baseline staging scan
docker run -t ghcr.io/zaproxy/zaproxy:stable zap-baseline.py \
  -t https://staging.example.com \
  -r zap-report.html

# SCA: upload manifest or SBOM to Vulert
# https://vulert.com/abom

Migration Checklist to Replace Checkmarx Safely

A safe migration should avoid a visibility gap. Do not turn off Checkmarx until the replacement tools are running, reporting, and creating tickets for new findings. Run both systems in parallel for at least 2-4 weeks if you still have access. Compare Critical and High findings, review false positives, and confirm developers know where new security tickets will appear.

For SCA, export any available SBOMs or dependency reports before access ends. Store them by application and release. Then upload representative SBOMs or manifests to Vulert to confirm coverage. For SAST, run Semgrep against the top 5 active repositories and compare findings against the highest-priority Checkmarx SAST findings. For IaC, run Checkov against active Terraform and Kubernetes repositories. For API testing, run ZAP against staging endpoints that have safe test data.

Export evidence: Save Checkmarx reports, SBOMs, open findings, suppression lists, and remediation history before access ends.
Map capabilities: Decide which tool replaces SAST, SCA, IaC, API testing, and reporting.
Run parallel scans: Compare old and new findings for Critical and High issues before switching workflows.
Create triage rules: Define what blocks builds, what creates tickets, and what goes into backlog.
Document ownership: Assign owners for code scanning, dependency scanning, infrastructure scanning, and API testing.
Review after 30 days: Measure finding volume, false positives, time to fix, and developer feedback.

When Checkmarx Still Makes Sense

Checkmarx still makes sense for organizations that need one mature enterprise platform across many teams, business units, languages, and governance workflows. If your company has hundreds of repositories, strict compliance reporting, centralized AppSec ownership, custom policy needs, and the budget to support enterprise implementation, Checkmarx can be a good fit.

The alternative stack makes more sense when the team is smaller, cost matters, and the highest priority is practical remediation. A mid-size team may not need enterprise-level workflow complexity to fix vulnerable packages, catch obvious code patterns, scan Terraform, and test APIs in staging.

Use this rule: if your team spends more time administering the security platform than fixing findings, the tool may be too heavy for your stage. If your team cannot produce an audit-ready view of Critical and High vulnerabilities, your stack may be too light. The right replacement sits between those extremes.

Tip: Choose the smallest stack that gives you reliable coverage, developer adoption, and clear remediation evidence.

Key Takeaways

Checkmarx is a strong enterprise AppSec platform, but many mid-size teams do not need the full suite or enterprise pricing.
A practical Checkmarx alternative can combine Semgrep for SAST, Vulert for SCA, Checkov for IaC, OWASP ZAP for API testing, and an annual penetration test.
Teams should replace CxSCA first after a divestiture because new open source CVEs are disclosed daily and dependency visibility must continue.
Vulert Pro costs $540 per year and focuses on dependency vulnerability monitoring through manifest and SBOM analysis.
Semgrep can run useful SAST scans quickly with python3 -m pip install semgrep and semgrep --config=auto ..
The realistic replacement stack can cost around $9,000-$16,000 per year when paired with an annual boutique penetration test.

Frequently Asked Questions

1. What is the best free Checkmarx alternative?

The best free replacement depends on the capability. Semgrep is the best free starting point for SAST, Checkov is strong for IaC scanning, and OWASP ZAP works well for API and DAST baseline testing. For SCA, Vulert offers a free scanner at vulert.com/abom and paid continuous monitoring at much lower cost than enterprise platforms.

2. How do I replace Checkmarx SCA specifically?

Export your dependency files or SBOMs, then upload them to Vulert. Vulert accepts common manifest files and CycloneDX/SPDX SBOMs, shows known CVEs, provides exact fixed versions, and includes CLI fix commands. This is the fastest Checkmarx SCA replacement path for teams that need dependency vulnerability visibility immediately.

3. Why do teams say Checkmarx is too expensive?

Teams usually say Checkmarx is too expensive when they are paying for an enterprise platform but mainly using SCA or basic SAST. For sub-200-person companies, a smaller stack can cover common remediation workflows at a fraction of the annual cost.

The EU Cyber Resilience Act — What Software Engineering Teams Need to Know in 2026

Vulert — Wed, 29 Jul 2026 07:00:00 +0000

EU cyber resilience act software requirements are moving from legal text to engineering work. Teams selling software, connected products, hardware with software, or IoT devices into the EU now need practical processes for vulnerability handling, SBOMs, secure updates, and reporting.

The Cyber Resilience Act entered into force on 10 December 2024. Reporting obligations begin on 11 September 2026, and the main obligations apply from 11 December 2027. That timeline gives software teams limited time to turn dependency visibility, vulnerability monitoring, and security documentation into repeatable engineering processes.

What the EU Cyber Resilience Act Is

The EU Cyber Resilience Act, or CRA, establishes cybersecurity requirements for products with digital elements made available on the EU market. A product with digital elements can include software, hardware with embedded software, connected devices, IoT products, firmware-driven systems, and other digital products that connect directly or indirectly to a network.

For software teams, the CRA matters because it turns security practices into product obligations. The regulation expects manufacturers to build products with cybersecurity in mind, handle vulnerabilities across the product lifecycle, provide security updates, maintain technical documentation, and report certain serious events. This affects engineering, product management, DevOps, security, compliance, and customer support workflows.

The CRA applies mainly to manufacturers placing products with digital elements on the EU market, but importers and distributors also have duties. A non-EU company can still be affected if it sells covered products to EU customers. That is why engineering teams outside Europe should not ignore the regulation if their product reaches the EU market.

The most relevant operational areas for software teams are vulnerability handling, dependency monitoring, component inventory, SBOM generation, secure update processes, and evidence. These are not one-time tasks. They require a running process that can detect newly disclosed CVEs, assign fixes, document remediation, and support reporting timelines.

Key Dates — When Does This Apply to You?

The CRA timeline matters because different obligations begin at different times. The regulation entered into force on 10 December 2024. The first major operational deadline for many manufacturers is 11 September 2026, when reporting obligations for actively exploited vulnerabilities and severe incidents begin. The main CRA obligations apply from 11 December 2027.

Engineering teams should treat 2026 as the preparation year. Waiting until late 2027 creates a documentation and process gap. If your team sells into the EU and has no SBOM process, no continuous vulnerability monitoring, no vulnerability disclosure policy, and no remediation evidence, you may need several months to create a credible program.

The reporting deadline is especially important because the clock starts when the manufacturer becomes aware of an actively exploited vulnerability or severe incident. If your monitoring process is slow, manual, or inconsistent, you may struggle to meet the 24-hour early warning expectation after awareness.

Date	Milestone	Engineering Meaning
10 December 2024	CRA entered into force.	The regulation is active, and teams should begin preparation.
11 September 2026	Reporting obligations begin.	Manufacturers must report actively exploited vulnerabilities and severe incidents through the required channels.
11 December 2027	Main obligations apply.	Products with digital elements must meet the broader CRA requirements.

Warning: The 2026 reporting deadline arrives before the full 2027 application date. Do not wait until 2027 to build vulnerability monitoring and reporting workflows.

Does the CRA Apply to Your Company?

The CRA can apply to any company that makes or sells products with digital elements into the EU market. This includes commercial software vendors, SaaS-adjacent product companies, IoT manufacturers, hardware vendors with firmware, industrial device makers, security appliance vendors, and companies distributing connected products under their own name.

The key question is not only where your company is located. The question is whether your product is made available on the EU market. A UK, US, Pakistani, Canadian, Indian, or Singaporean company may still need to prepare if EU customers buy or use its covered products. Importers and distributors may also ask vendors for evidence because they have their own obligations in the supply chain.

Purely non-commercial open source projects receive important treatment under the final CRA text, but commercial products that incorporate open source components do not automatically escape responsibility. If your company ships a paid product that includes lodash, log4j-core, openssl, requests, jackson-databind, or other third-party components, your company remains responsible for managing product risk.

Use the table below as a practical engineering filter, not legal advice.

Situation	Likely CRA Relevance	What to Do
You sell commercial software to EU customers.	High relevance.	Prepare SBOM, vulnerability handling, monitoring, and documentation processes.
You sell IoT or hardware with firmware in the EU.	High relevance.	Map firmware components, update channels, and vulnerability reporting workflows.
You maintain a free non-commercial open source project.	Specific exemptions may apply.	Confirm treatment with legal counsel before assuming obligations.
Your commercial product uses open source packages.	High relevance.	Track open source CVEs because the commercial product carries the responsibility.

What the CRA Requires — The Open Source Dependency Angle

EU cyber resilience act software preparation should start with open source dependency visibility. Modern software products are built from third-party packages, frameworks, libraries, SDKs, and transitive dependencies. If a product includes a vulnerable component, the manufacturer needs a process to know about it, assess it, remediate it, and document the decision.

The CRA does not only ask teams to react after incidents. It pushes manufacturers toward secure-by-design development, vulnerability handling, documented components, coordinated vulnerability disclosure, and ongoing security support. For engineering teams, that translates into dependency inventory, SBOM generation, automated CVE monitoring, remediation SLAs, ticketing, release documentation, and evidence history.

A practical CRA readiness process should answer 5 questions: What components are in the product? Which components have known CVEs? Which vulnerabilities are actively exploited? Who owns remediation? Can the team prove when the issue was found, fixed, and verified?

Vulnerability Handling Requirements

Vulnerability handling means the company has a documented process to receive, assess, prioritize, fix, and disclose security vulnerabilities. For software teams, this includes vulnerabilities in first-party code and third-party dependencies.

A working vulnerability handling process should include ownership, severity rules, remediation timelines, exception handling, customer communication, and evidence storage. For example, a team may require Critical CVEs to receive review within 24 hours, emergency fixes within 48 hours where a patch is available, and documented mitigations when no patch exists.

Dependency monitoring supports this requirement because teams cannot address vulnerabilities they do not know about. Continuous SCA monitoring helps identify newly disclosed CVEs affecting specific packages and gives engineering owners the data needed to act.

SBOM Requirements

Software Bill of Materials, or SBOM, is a machine-readable inventory of software components. The CRA references the need to identify and document components, including third-party and open source components. For engineering teams, that means generating and maintaining SBOMs or equivalent component records for products sold into the EU.

Common SBOM formats include CycloneDX and SPDX. Teams can generate SBOMs using tools such as Syft or CycloneDX CLI, then store them with release artifacts. SBOMs should be updated when dependencies change, not created once and forgotten.

# Generate a CycloneDX SBOM from the current project directory
syft dir:. -o cyclonedx-json > sbom.json

# Generate an SPDX SBOM from the current project directory
syft dir:. -o spdx-json > sbom-spdx.json

The 24-Hour ENISA Reporting Requirement

ENISA reporting becomes operationally important from 11 September 2026. Manufacturers must report actively exploited vulnerabilities and severe incidents affecting product security through the required reporting process. ENISA is preparing the Single Reporting Platform to support these notifications.

The early warning requirement creates a speed problem for engineering teams. You need to know when a vulnerability is actively exploited, whether your product includes the affected component, and whether your product is impacted. That requires inventory, monitoring, triage ownership, and escalation paths.

Continuous monitoring does not replace legal review or official reporting decisions, but it helps engineering teams detect relevant CVEs quickly enough to support the reporting process.

The Open Source Nuance — Who Is Responsible?

EU CRA open source discussion caused concern because maintainers worried that the regulation could impose heavy obligations on volunteer open source projects. The final framework includes important nuance for open source software that is not commercialized and not provided as part of a commercial activity.

Commercial product teams should not misread that nuance. If your company incorporates open source components into a commercial product, your company must manage the security risk of the product you place on the market. The maintainer of a package such as lodash, log4j-core, urllib3, openssl, or jackson-databind does not become your compliance team.

This is the standard SCA use case. Your team needs to know which packages are present, which versions are vulnerable, which fixed versions exist, and whether exploitation affects your product. The fact that you did not write the dependency does not remove the need to track it.

Under the CRA, commercial products incorporating open source components inherit responsibility for those components. The open source maintainer is not your vulnerability management process.

Tip: Treat open source dependency monitoring as product security work, not as an optional developer hygiene task.

5 Practical Steps to Start CRA Preparation Now

CRA compliance software preparation should begin with processes engineering teams can implement now. You do not need to wait for every harmonized standard or final internal legal interpretation to start improving component visibility, vulnerability monitoring, SBOM generation, and remediation evidence.

The 5 steps below create a practical foundation for product teams. They help you answer customer security questions, prepare for audits, and support future CRA obligations.

Generate an SBOM for every product sold into the EU: Use Syft or CycloneDX tooling to create CycloneDX or SPDX SBOMs for each release. Store the SBOM with the product version, build date, and repository commit.
Establish continuous vulnerability monitoring: Use an SCA tool such as Vulert to monitor manifest files and SBOMs against CVE databases. Continuous monitoring helps teams detect new CVEs between code changes.
Write a vulnerability disclosure policy: Create a public or customer-facing process for reporting security issues. Define where reports go, who triages them, and what response timeline reporters should expect.
Document your remediation process: Write severity-based SLAs, assign owners, create Jira tickets for findings, and keep records showing when CVEs were found, fixed, and verified.
Track reporting timelines: Build escalation paths for actively exploited vulnerabilities and severe incidents. The 24-hour early warning requirement means teams need fast internal routing from engineering to leadership and legal review.

Step	Artifact to Produce	Owner
Generate SBOMs	CycloneDX or SPDX file per product release.	Engineering or DevOps.
Monitor dependencies	Continuous SCA dashboard and alert history.	Security or engineering lead.
Create VDP	Vulnerability disclosure policy page or document.	Security lead and legal counsel.
Document remediation	Severity SLA, Jira tickets, fix records, and scan history.	Engineering manager.
Track reporting	Escalation workflow for actively exploited vulnerabilities.	Security, leadership, and legal.

How Vulert Helps With CRA Dependency Readiness

EU cyber resilience act software preparation depends on knowing what components you ship and which CVEs affect them. Vulert helps with the dependency monitoring part of that process by scanning manifest files and SBOMs against 458,000+ known CVEs.

Vulert supports package-lock.json, yarn.lock, pom.xml, build.gradle, requirements.txt, Pipfile.lock, poetry.lock, composer.lock, go.sum, Gemfile.lock, Cargo.lock, pubspec.lock, mix.lock, *.csproj, packages.lock.json, and SBOM files in SPDX and CycloneDX formats. It supports PHP, JavaScript, Java, Python, Go, Ruby, Rust, Dart, Elixir, Erlang, C++, and C#/.NET.

The most relevant features for CRA preparation are continuous 24/7 monitoring, alerting within hours of new CVE disclosures, exact fix versions, CLI fix commands, Dependency Health grouping, Jira ticket creation, vulnerability history, and trend reports. These features help teams prove that vulnerability monitoring is not a one-time scan.

Vulert does not replace legal counsel, conformity assessment, or official reporting decisions. It supports the engineering evidence layer: component visibility, CVE detection, remediation guidance, and historical records. To strengthen your CRA preparation workflow, read these related Vulert guides:

Client Security Questionnaire — Open Source Section
Free Online Vulnerability Scanner Guide

These guides help connect CRA preparation with customer security questionnaires, dependency scanning, SBOMs, and continuous monitoring evidence.

Key Takeaways

EU cyber resilience act software readiness affects teams that sell products with digital elements into the EU market.
The CRA entered into force on 10 December 2024, reporting obligations apply from 11 September 2026, and main obligations apply from 11 December 2027.
Software teams should prepare SBOMs, vulnerability handling processes, continuous dependency monitoring, remediation evidence, and disclosure workflows.
Commercial products that include open source components remain responsible for managing vulnerabilities in those components.
The 24-hour reporting expectation for actively exploited vulnerabilities requires fast internal awareness, triage, and escalation.
Continuous SCA monitoring helps teams detect new CVEs affecting shipped packages between code changes and release cycles.

Frequently Asked Questions

1. Does the EU CRA apply to open source software?

The CRA includes important nuance for open source software that is not commercialized and not provided as part of commercial activity. Commercial products that include open source components still need to manage the security risk of those components. Ask legal counsel how the rule applies to your exact product and business model.

2. What does the EU CRA require for vulnerability management?

The CRA expects manufacturers to handle vulnerabilities across the product lifecycle. Engineering teams should maintain component inventory, monitor CVEs, document remediation, provide updates, and prepare reporting workflows for actively exploited vulnerabilities and severe incidents.

3. Do I need an SBOM for EU CRA compliance?

The CRA points teams toward identifying and documenting software components, including third-party and open source components. In practice, software teams should prepare CycloneDX or SPDX SBOMs for products sold into the EU and keep them updated with releases.