The software supply chain — third-party dependencies, build infrastructure, container base images, CI/CD pipelines, signing-key handling, third-party API integrations — has become a primary attack surface for software-shipping organizations. Multiple high-profile incidents over the past five years have moved supply-chain security from compliance checklist to operational priority.
This solution covers structured assessment across the supply-chain layers that matter for software-shipping organizations.
Where Melina engages on supply-chain security
SBOM tracking and dependency posture
A maintained Software Bill of Materials (SBOM) is the foundation of supply-chain risk management. Without an accurate, current SBOM, dependency-vulnerability response devolves into best-effort scanning and reactive triage.
We assess existing SBOM tracking — what’s covered, what’s missing, how it’s maintained, how it integrates with vulnerability response — and identify the gaps that an incident would expose. For organizations without existing SBOM practice, we support SBOM tooling selection (CycloneDX vs SPDX, build-time vs scan-time generation) and integration into the build pipeline.
Build infrastructure security
The build infrastructure — CI runners, build secrets, artifact signing infrastructure — is the supply-chain attack surface most often overlooked. A compromised CI runner can inject backdoors into release artifacts that no downstream consumer can detect.
Assessment scope:
- CI runner isolation and ephemeral-execution posture
- Build secrets handling — where they’re stored, who can access them, rotation cadence
- Release artifact signing — key custody, signing-key access control, signing infrastructure attack surface
- Build reproducibility — whether the build is deterministic enough to detect tampering
- Admission control on release-deploy pipelines
Container and image supply-chain
For organizations shipping containerized software:
- Base image provenance and update cadence
- Image signing (cosign, notation, in-toto attestations)
- Admission policy enforcement (Sigstore policy-controller, Kyverno, OPA Gatekeeper)
- Registry security and access control
- Vulnerability scanning integration and finding triage
Third-party-service risk inventory
Modern SaaS architecture incorporates dozens of third-party services — observability, error tracking, feature flags, auth providers, payment processors, data-processing services. Each is a potential supply-chain attack vector, particularly through credentials granted at integration time.
Assessment scope: third-party-service inventory, credential scope assessment, vendor security posture review (where vendor-provided SOC 2 or ISO 27001 attestations exist), and incident-response plan coverage for vendor-side compromises.
Source-code repository security
Source-code repositories are often the highest-leverage target in the supply chain. Assessment scope: branch protection, code review enforcement, commit signing, repository access control, secret scanning integration, dependency-update automation security.
What this solution does not include
- Penetration testing of third-party services themselves — those are out of scope and out of authorization
- Replacement vendor selection — operator-driven with our advisory input as appropriate
Service mapping
Supply-chain security assessment draws across:
- Architecture & Cloud Review — primary service
- GRC services — for vendor-risk management process design
Compliance and standards frame
- NIST SP 800-218 (Secure Software Development Framework — SSDF)
- NIST SP 800-161 (Cybersecurity Supply Chain Risk Management)
- ISO/IEC 27001:2022 Annex A (supply-chain controls)
- AICPA Trust Services Criteria (SOC 2)
- EU Cyber Resilience Act (CRA) — supply-chain elements
- SLSA framework (Supply-chain Levels for Software Artifacts)
- CIS Software Supply Chain Security Guide
Engagement model
Supply-chain assessment is typically Scoped Assessment. For ongoing supply-chain risk management — recurring SBOM review, vendor-onboarding security review, incident-response coordination — typically Retainer.
Concrete artifacts we look at
To make the engagement frame concrete, an assessment typically draws on the following materials provided by the customer:
- The latest SBOM exports (CycloneDX or SPDX format) for the systems in scope
- Lockfiles (package-lock.json, yarn.lock, poetry.lock, Pipfile.lock, go.sum, Cargo.lock) for build reproducibility validation
- CI/CD pipeline definitions (GitHub Actions workflows, GitLab CI files, Buildkite pipeline configs)
- Container manifests and registry policies (Dockerfile, base-image versioning, image-signing configuration)
- Vendor inventory and integration scope (third-party services with their credential scope and data access)
- Branch-protection and code-review configuration exports
- Existing vulnerability-scanning tool configuration and finding history
We work from these materials in the early phase of the engagement to focus the hands-on assessment on the highest-value targets.
Typical engagement timeline
For a SaaS organization with an established CI pipeline and partial SBOM coverage:
- Week 1: Material intake and gap analysis against the SLSA framework, NIST SSDF, and ISO 27001:2022 Annex A controls
- Weeks 2-3: Build-infrastructure assessment, including CI runner posture, secret management, signing-key custody
- Weeks 4-5: SBOM coverage validation, vendor-integration inventory, registry-and-admission-policy review
- Week 6: Reporting, with a prioritized remediation roadmap and a recommended ongoing-process design
For organizations operating at scale across multiple services or business units, the same shape extends across a quarter under Retainer with monthly checkpoint sessions.
Where this fits among compliance frameworks
Supply-chain assessment maps onto specific control families across the major frameworks. For SOC 2, this work contributes evidence to CC8.1 (change management), CC9.1 (risk mitigation), and the CC9.2 vendor-management criteria. For ISO 27001:2022, it directly addresses Annex A controls 5.20 through 5.23 (supplier relationships) and 8.30 (outsourced development).
Customers running a parallel ISO 27001 / SOC 2 readiness engagement often consolidate the supply-chain work into that engagement; standalone supply-chain engagements typically suit teams that have completed compliance attestation and want a deeper technical pass.
For automotive customers, the supply-chain assessment frame aligns with the supplier-coordination obligations under ISO/SAE 21434 — the cybersecurity-interface agreement work in automotive engagements draws on the same artifacts.
How to start
The lightest entry point is a 2-week diagnostic scoping engagement: we review the existing SBOM coverage, build-infrastructure documentation, and vendor inventory, and report back on which deeper-assessment scope would produce the highest finding density for your stage. From there, the full engagement scope is shaped to your organization’s risk priority.
“Most supply-chain assessments find the same gap — existing scanning tooling produces too many findings, the engineering team filters by familiarity rather than by impact, and the highest-impact supply-chain risks live in the build infrastructure and signing-key handling that scanners don’t cover. The Procurement Responsiveness Profile gives buyers a structured way to evaluate vendor responsiveness at component-selection time rather than discovering the gap during incident response.” — Tatiana K., CEO, Melina Security
Frequently asked questions
Will supply-chain assessment require access to our build infrastructure secrets?
We assess the design and configuration of credential handling without requiring direct access to production secrets. Where credential rotation, secret-scanning, or access-control review needs operational testing, we coordinate with the client team to execute the testing on the client’s infrastructure rather than transferring secrets to ours.
How does this work with our existing vulnerability-scanning tooling?
Existing tooling (Snyk, Dependabot, Trivy, Grype, container-registry scanning) is the starting point for the assessment. We evaluate coverage, integration into the engineering workflow, and finding-triage effectiveness — typically the tooling is already in place but the process around it is incomplete.
Do you provide supply-chain risk monitoring as a service?
No — our deliverable is assessment and process design. Ongoing risk monitoring is typically operated through commercial supply-chain platforms and the client’s own security operations.
How should procurement teams evaluate vendor security posture before selection?
The most useful structured framework we publish is the Procurement Responsiveness Profile — three dimensions (Disclosure Cadence, Time-to-Fix, Coverage Breadth) that let procurement teams compare components on signal quality rather than raw CVE count. A component with steady disclosure cadence and rapid fix-availability is structurally healthier than a component with zero historical CVEs and an unclear PSIRT process. The framework applies to both software components and the silicon / firmware vendors that ship into connected products.
What’s the relationship between SBOM hygiene and supply-chain assessment?
SBOM hygiene is the foundational layer — an accurate, build-time SBOM with format compatibility (CycloneDX, SPDX) is the input to any meaningful supply-chain assessment. Most teams have partial SBOM coverage (third-party components inventoried, first-party modules not, build-pipeline integration incomplete). Closing the SBOM coverage gap is usually the first remediation item from an assessment because subsequent control improvements depend on the SBOM being current.
Related
- What is SBOM?
- Architecture & Cloud Review service
- Industries — Cloud and SaaS companies
- Solutions — ISO 27001 & SOC 2 readiness
- Companion research: IoT Supply-Chain Vulnerabilities — Procurement Responsiveness Profile