Software Composition Analysis for dependencies | Anexia

For dependency scanning, we record direct and transitive components and their use in the build and at runtime. A library can be visible in the repository without being contained in the delivered artefact. Conversely, build steps can introduce further components. The assessment therefore needs a traceable link between source state, resolved dependencies and published version.

In component analysis, a known finding is not treated solely according to its general severity. We check the affected version, how it is integrated and the available information on actual usage. This does not replace a security analysis, but it improves prioritisation. For Software Composition Analysis, we define an update path that takes technical compatibility and the availability of fixes into account. An upgrade may require changes to interfaces or runtime behaviour and needs appropriate testing. Licence information is provided as verifiable inventory data; legal decisions remain with the responsible department. In this way, SCA integration combines transparency about components with an executable process for assessing and resolving relevant issues.

Scope of services for Software Composition Analysis

The agreed scope for dependency scanning can include the following deliverables: dependency inventory, scan rules, finding assignment, update workflow and evidence for delivered versions. For each key deliverable, we define what it is for, who reviews it and in what form it is handed over. This allows development, operations and procurement to assess the same service. Vague umbrella terms in the offer are replaced by concrete work packages.

Component analysis also includes coordinating the necessary interfaces with your team. We clarify access, contact persons and available testing options before the relevant implementation steps. Changes to the scope are described together with their impact on effort and sequence. This gives you a clear overview of delivered results, outstanding prerequisites and additional requests.

The key technical decision in Software Composition Analysis

Direct and transitive dependencies are considered separately. The assessed version must match the application actually built. For SCA integration, we document the relevant assumptions and justify the chosen option. Key alternatives are considered against the same functional requirements. This makes later adjustments easier when load, data volume or organisational responsibility change.

A sound decision also takes maintainability and handover into account. In dependency scanning, we check which skills are available internally and what additional support is needed. Technical possibilities are thus linked to a realistic operating model. The client can see which tasks will arise regularly after the project and which decisions remain with them.

A version match alone does not yet tell you whether the vulnerable function is reachable or whether a proposed update remains compatible. In component analysis, we treat this point as a concrete test question. A risk is linked to the affected process, its possible impact and a suitable measure. Where prerequisites are still missing, the statement explicitly remains open until the necessary investigation has taken place.

We check detection coverage, version mapping, licence information and the path that leads each finding to a tested update. For Software Composition Analysis, we record the initial situation, the tested configuration and the result. Acceptance refers to the agreed scope. Open limitations are visibly documented and assigned to an owned next step. This allows your team to distinguish between proven functionality, a deliberate decision and an assumption not yet confirmed.

Project example as an illustrative scenario

The following scenario is a use case example and not a customer reference. An application contains many indirect library dependencies whose actual use in the product is unclear. In Software Composition Analysis, the investigation would begin with a specific delivered version. Development tools, build dependencies and components in the production package would be recorded separately. Only then could it be seen which finding affects which part of the supply chain.

For SCA integration, package lists and resolved versions would be compared with the actual artefact. An indication of a vulnerable library would be assessed with regard to affected functions and usage context. An update could entail further version changes; compatibility tests and fallback options would therefore be part of the action plan. In the pilot, a selected dependency would be updated and the entire delivery path up to the production package would be verified. Licence notices would be recorded and passed on to the responsible specialist departments where an assessment is needed.

The result of dependency scanning would be a prioritised and technically feasible update plan. The number of reported vulnerabilities alone would describe neither exploitability nor business risk. The plan would include a reliable component inventory, documented assessments and verified changes. For new findings, it would then have to be clear who maps them to a product, investigates their significance and follows the necessary measures through until the fix has actually been delivered.

Our experience and our engineering approach

We combine custom software development with the technical tasks of introduction and further development. For SCA integration, we bring the perspectives of application, integration and operations together in a shared workflow. Business requirements remain linked to technical decisions. You work with a defined scope of services and traceable results.

Our experience should become concretely verifiable for your project. That is why, in a technical exchange, we explain how we examine the relevant risks, which deliverables are planned and how your team can assess them. For dependency scanning, we align the roles involved with actual needs. Available references are presented in the context of the respective project and company; confidential customer details are not used as general advertising claims.

Effort for dependency scanning

The number of ecosystems, private packages, maintenance of parallel versions and automatable regression tests determine the effort. We therefore calculate Software Composition Analysis on the basis of a defined scope and explicitly stated prerequisites. An initial analysis step can be useful if essential technical information is still missing. Work packages and acceptance criteria can then be agreed more reliably.

SCA integration can be organised as a limited project, as a joint implementation with your team or with subsequent support. Usage rights, access, documentation and responsibilities are clarified in the contract. Ongoing operating hours, response times and external consumption costs are separate agreements. This makes it clear which services are provided once and which tasks arise regularly after introduction.

Scope boundaries of Software Composition Analysis

Technical licence inventory does not replace a legal assessment of specific usage and distribution scenarios. For component analysis, we already record this boundary in the offer. Required additional services are included with their functional justification and not tacitly assumed. Your team can therefore plan suitable internal skills and divide the overall work sensibly between those involved.