Open Source Security

Take Control of Dependency Risks:
SCA Security Analysis

Software Composition Analysis (SCA)

Modern software is 80-90% composed of open source components. Security vulnerabilities in these components, licence incompatibilities and outdated versions carry serious risks. With our SCA service we analyse your third-party dependencies, detect known vulnerabilities and make your software supply chain transparent with an SBOM (Software Bill of Materials).

What Do We Offer? How Does the Process Work? Schedule a Meeting

What Do We Offer? SCA Service Scope

We treat the SCA engagement not as a mere "vulnerability scan" but as the holistic management of software supply chain security. Dependency inventory, vulnerability analysis, licence compliance checks and SBOM generation are delivered under one roof.

Dependency Inventory (SBOM)

All direct and transitive dependencies are identified. An SBOM is produced in CycloneDX or SPDX format, creating the software bill of materials. This inventory is the core input for audit, compliance and risk management.

CVE / Vulnerability Analysis

Components are matched against NVD, OSV, GitHub Advisory and commercial databases to detect known vulnerabilities. For each CVE, the CVSS score, exploitation status (EPSS), impact analysis and remediation recommendation are provided.

Licence Compliance Checks

Licences such as GPL, LGPL, MIT and Apache are identified and compared with corporate policies. Components carrying incompatibility risk are flagged; legal/commercial risk assessment is supported.

Version / EOL Tracking

The currency of the components used, their support status (End-of-Life) and comparison with the latest available versions are assessed. Outdated, no-longer-supported components are reported as risks.

Prioritisation (Triage)

Rather than treating all CVEs as equal, prioritisation is based on exploitability (EPSS), reachability, business impact and component criticality. Teams proceed in the right order.

CI/CD Integration Support

Teams wishing to integrate SCA into the development process receive guidance on pipeline design, threshold definitions and automated control mechanisms.

Who Is It For? Target Audience and Scenarios

Every software project using open source components is a potential SCA candidate. SCA is especially critical for organisations facing regulatory pressure, supply chain transparency requirements and fast delivery needs.

  • Enterprise product teams: Projects using hundreds of dependencies from ecosystems such as Node.js, Java, Python and .NET.
  • Regulation-driven sectors: Companies subject to regulations imposing SBOM obligations, such as NIS2, FDA Cybersecurity and PCI DSS 4.0.
  • Software suppliers: Companies that must provide their customers with an SBOM, a security report and a licence compliance document.
  • M&A / Due Diligence: Those wishing to assess the security and licence risks of software assets before an acquisition or investment.
  • DevSecOps transformation: Those wishing to bring the "shift-left" approach to life by integrating security into the pipeline.

Why Is SCA Critical?

The Log4Shell (CVE-2021-44228) incident showed how a single open source component can affect millions of systems worldwide. SCA detects such risks proactively, provides visibility against supply chain attacks and builds the SBOM infrastructure required by regulations. It offers controlled risk management instead of reactive "firefighting".

Critical CVE

Actively exploited vulnerabilities carrying remote code execution risk

Licence Risk

Incompatibility of copyleft (GPL) licences with commercial products

EOL Component

Libraries no longer receiving updates, out of support

Version Lag

Components falling behind the current version, creating technical debt

How Does the Process Work? Dependency-to-Decision Pipeline

We treat SCA not as a "one-off scan" but as a structured process involving inventory extraction, analysis, prioritisation and closure validation. We offer a framework adaptable to different project scales.

Scope and Access

The project structure, the package managers used (npm, Maven, pip, NuGet, etc.), mono-repo/multi-repo status and the targeted outputs are clarified. The access model is defined.

Dependency Discovery

Manifest files (package.json, pom.xml, requirements.txt, etc.) and lock files are analysed to identify all direct and transitive dependencies.

Vulnerability and Licence Scanning

The identified components are matched against CVE databases and licence catalogues. For each finding, the CVSS score, EPSS, exploit status and licence type are determined.

Prioritisation (Triage)

Findings are prioritised by exploitability, reachability, business impact and component criticality. We operate on the principle that "not every CVE is equal".

Reporting and SBOM

An executive summary, a technical report and an SBOM (CycloneDX/SPDX) are produced. For each finding, remediation guidance and upgrade path information are provided.

Re-scan and Closure

After fixes, a re-scan is performed to confirm closure. Remaining risks, accepted exceptions and technical debt areas are documented.

Why Does Reachability Analysis Matter?

A CVE existing in a component does not mean that CVE is exploitable in your code. Reachability analysis checks whether the vulnerable function is actually used. This reduces "noise", lets teams focus on real risks and avoids unnecessary upgrade costs.

Deliverables Usable and Compliant

The deliverable set is structured to enable rapid action by technical teams, risk visibility for management and audit requirements for compliance teams.

SBOM (CycloneDX/SPDX)
A standard-format listing of all components. A machine-readable inventory compliant with NIS2, FDA Cybersecurity, PCI DSS 4.0 and EO 14028 requirements.
Executive Summary
Aggregation of risk themes, highlighting of critical findings, an overall security posture assessment. Produces a clear answer to "what should we focus on?"
Technical Detail Report
CVE-level details, affected component/version, CVSS/EPSS scores, exploit status, remediation recommendation (upgrade path) and alternative component suggestions.
Licence Compliance Matrix
The licence types of all components, their compliance status against corporate policies and potential legal/commercial risks.
Prioritised Action List
Verified findings after triage, structured with priority, component, current/target version and estimated impact information.
Re-scan / Closure Validation
Re-scan and closure confirmation after fixes. Remaining risks, accepted exceptions and technical debt areas are documented.

Frequently Asked Questions About SCA

Positioning SCA correctly starts with clarifying expectations. The answers below address the topics organisations most frequently clarify.

What is the difference between SCA and SAST?
SAST analyses the code you write (first-party code). SCA analyses the third-party components you use (third-party/open-source). Since the vast majority of modern software consists of open source components, the two methods complement each other. A comprehensive AppSec programme should include both SAST and SCA.
What is an SBOM and why does it matter?
An SBOM (Software Bill of Materials) is the list of all components used in your software. Think of it as a "bill of materials". Regulations such as NIS2, FDA Cybersecurity, PCI DSS 4.0 and US EO 14028 make SBOMs mandatory. The SBOM is the core input for vulnerability management, licence compliance and supply chain transparency.
Why do transitive dependencies create risk?
A component you add directly (A) may depend on other components (B, C). These "dependencies of dependencies" are transitive dependencies. As in the Log4Shell example, even if you never use Log4j directly, you can be affected through another component. SCA makes these hidden dependencies visible.
How often should SCA scanning be performed?
Ideally, automated scanning should run on every commit/PR via CI/CD integration. As a minimum: before major releases, periodic (monthly/quarterly) checks and emergency scans upon critical CVE announcements (such as Log4Shell) are recommended. Continuous monitoring provides proactive rather than reactive security.
What does licence incompatibility mean?
Some open source licences (such as GPL and AGPL) are "copyleft" and require derivative works to be shared under the same licence. Using such components in a commercial, closed-source product can create legal and commercial risks. SCA detects these incompatibilities and enables proactive management.

Take Control of Your Open Source Dependencies

Make your software supply chain transparent, detect known vulnerabilities and build the SBOM infrastructure for your regulatory requirements. Let's define the SCA scope together.

[email protected] Contact Page