Third-party risk doesn’t only concern the security position of a supplier’s organization; it also exists in the software that a business imports, distributes, or uses. A component can still give rise to vulnerability, licensing, or maintenance risks even if the supplier has filled out an impressive security questionnaire.
Tools for ensuring the security of software supply chains can be used to examine the technical dependencies and artifacts in question. However, they cannot take the place of a comprehensive vendor risk program which includes considerations of contracts, data handling, resilience, and organizational controls. The following list concentrates on the aspect of third-party risk at the component level, that is, on understanding what the software contains, how risky those components are, and identifying who is responsible when the evidence changes.
At a glance
| Aikido Security | Developer-owned component risk | SCA and SBOMs |
| Black Duck SCA | Detailed component discovery | Source and binary |
| FOSSA | License and supplier evidence | Component governance |
| Sonatype Lifecycle | Consistent component policy | Open-source governance |
| Endor Labs | Dependency impact analysis | Reachability-based context |
| OWASP Dependency-Track | SBOM portfolio monitoring | Component inventory analysis |
1. Aikido Security — Developer-owned component risk
Aikido’s dependency security tools combine vulnerability assessment with malware and license-related signals. Its SBOM capabilities can support component inventory, while remediation workflows connect findings to the engineers maintaining the software.
The situation is suitable for a company which is assessing the risks associated with open source in its own products or in any software that it is authorized to examine. It is important to make the distinction between scanning a codebase that is being maintained and evaluating the supplier’s organisation. A list of imported components should be used as evidence for analysis, not as proof that the supplier’s overall controls or its business continuity plans are adequate.
2. Black Duck SCA — Detailed component discovery
Black Duck SCA enables the discovery of open-source components by using a variety of analysis methods, such as those focused on source code and those focused on binary code. The tool is appropriate in cases where the software being assessed is more complex than a simple dependency manifest.
That aspect is important when giving reviews of commercial software or when dealing with codebases that have declared dependencies which do not give the full picture. Choose the appropriate edition and analysis technique based on the materials available. The useful result will be a defensible component inventory and risk assessment, with uncertainty retained in cases where provenance or version information cannot be established with confidence.
octopusintelligence.com | Article 14 / continued
3. FOSSA — License and supplier evidence
FOSSA offers software composition analysis, license compliance, and other features relating to SBOMs, as well as methods for assessing supplied software; it should be taken into account in cases where legal and procurement teams need component evidence together with vulnerability information.
We need to specify the decision that the evidence should support. The level of detail required in a legal review of distributed software is different from that needed in a developer’s update recommendation. It is important to find out how obligations, exceptions, and supplier-provided inventories are kept under review over time. While software analysis can identify problems worth looking at, it should not be treated as a replacement for a qualified interpretation of contractual or licensing obligations.
4. Sonatype Lifecycle — Consistent component policy
Sonatype Lifecycle includes policies designed to address open-source component risk during the development process, and it should be considered in cases where a business wants to establish consistent standards for the dependencies that teams can use and the conditions under which they can do so.
With regard to third-party risk, what is important is consistency not a single score. You need to work out how a component which has previously been accepted is to be re-evaluated when new information comes to light. The policy should specify who is authorised to approve an exception, for how long that approval is valid, and what evidence is required in the case where a supplier is unable to give a corrected release immediately.
5. Endor Labs — Dependency impact analysis
Endor Labs applies dependency reachability analysis in order to be able to tell apart component vulnerabilities based on how they relate to the application code, since this is relevant when a business wants to know whether a dependency problem is likely to affect the way the product uses that component.
A robust assessment should involve a realistic build and should recognize the presence of uncertainty. While reachability can be used to adjust remediation priorities, it does not prove a supplier’s overall trustworthiness nor does it eliminate other risks such as malicious package behaviour. The analytical conclusion should be more specific than the commercial decision it supports.
6. OWASP Dependency-Track — SBOM portfolio monitoring
OWASP Dependency-Track is an open-source tool which is used for analysing component inventories, especially by means of software bills of materials; it is useful in cases where an organisation wants to keep an eye on the dependencies found in a number of applications or in software inventories provided by suppliers.
How effective it is relies very much on the quality and freshness of the inventories. Agree on the product version, the generation date, and the update procedure for each SBOM provided. An inventory which refers to a release from last year can result in a very accurate-looking assessment of software that the company no longer uses.
Turn supplier evidence into a maintained decision
Begin with Aikido when carrying out developer-owned remediation, use Black Duck for more thorough component discovery, and choose FOSSA for license-related evidence. For common policies refer to Sonatype, for application impact context use Endor Labs, and for SBOM-based monitoring select Dependency-Track.
Get inventories that are linked to specific released versions, record any unresolved questions, and set up a notification and remediation contact. Separate the findings regarding components from the organisation’s overall vendor assessments and bring them together at the point when decisions are made. The aim is not to permanently label a supplier as safe or unsafe; rather, it is to keep up to date enough evidence so that a decision can be made as to whether a particular software dependency is still acceptable for a particular business use.
