21.2 Integrating with Existing Security Programs¶

Supply chain security does not exist in isolation. Organizations already have application security programs, vulnerability management processes, third-party risk management frameworks, and incident response capabilities. The question is not whether supply chain security relates to these existing functions—it clearly does—but how to integrate effectively without creating duplicative processes, conflicting tools, or organizational confusion.

When integration fails, the consequences are visible: the same vulnerability appears in three different tracking systems with three different severity ratings; engineering teams receive alerts from multiple tools for the same dependency issue; incident response teams lack playbooks for supply chain-specific scenarios. Conversely, well-integrated programs leverage existing capabilities, fill genuine gaps, and present a unified view of risk to stakeholders.

This section examines how supply chain security intersects with adjacent security domains and provides practical guidance for integration.

Relationship to Application Security¶

Application Security (AppSec) programs focus on securing the software an organization develops, typically through secure coding practices, security testing, and code review. Supply chain security overlaps significantly with AppSec—both concern the security of software assets—but addresses different aspects of the problem.

Overlap and differentiation:

Aspect	Application Security	Supply Chain Security
Primary focus	Code written in-house	Code obtained externally
Testing methods	SAST, DAST, penetration testing	SCA, provenance verification
Remediation owner	Development team	Development team (but fix may come from upstream)
Vulnerability source	Internal coding errors	External components
Control point	Code review, CI/CD	Dependency selection, package management

In practice, both disciplines share the CI/CD pipeline as a primary control point. A modern secure development pipeline includes:

Static analysis (SAST) for in-house code
Software composition analysis (SCA) for dependencies
Dynamic testing (DAST) for runtime behavior
Container scanning for deployment artifacts

Integration approaches:

Unified pipeline: Integrate supply chain security checks into existing AppSec pipeline stages rather than creating parallel processes.
Shared findings management: Route dependency vulnerabilities through the same triage and tracking system as application vulnerabilities.
Coordinated policies: Align supply chain security policies (e.g., acceptable risk thresholds) with AppSec policies.
Combined training: Include supply chain security topics in secure development training programs.

Organizations with mature AppSec programs often extend them to cover supply chain security rather than building separate capabilities. The AppSec team gains responsibility for dependency scanning and evaluation, leveraging existing relationships with development teams. This approach avoids creating parallel processes and capitalizes on existing developer trust and workflow integration.

Relationship to Third-Party Risk Management¶

Third-Party Risk Management (TPRM) programs assess and monitor risks from vendors, suppliers, and partners. Open source dependencies represent a form of third-party relationship, albeit one with different characteristics than commercial vendor relationships.

Integration points:

TPRM Concept	Supply Chain Security Application
Vendor assessment	Dependency evaluation criteria
Ongoing monitoring	Vulnerability monitoring for dependencies
Contractual requirements	License compliance, security requirements
Risk tiering	Dependency criticality classification
Exit planning	Migration planning for high-risk dependencies

Adapting TPRM for open source:

Traditional TPRM approaches require modification for open source:

No contract: Open source licenses grant rights but create no obligations for maintainers to fix vulnerabilities or provide support
No SLA: Response times depend on maintainer availability and interest
Community as vendor: The "vendor" is often an individual or small group of volunteers
Public visibility: Unlike commercial vendors, open source security is publicly visible (for better and worse)

Many organizations create a modified TPRM process for open source, applying risk assessment principles while acknowledging the different relationship model:

# Open Source Component Risk Assessment

### Maintainer Assessment
- Active maintenance? (commits in last 6 months)
- Security responsiveness? (historical CVE response times)
- Multiple maintainers? (bus factor)
- Foundation backing? (Linux Foundation, Apache, etc.)

### Component Assessment
- Security posture? (Scorecard rating)
- Known vulnerabilities? (current CVE count)
- Criticality to our use case?
- Availability of alternatives?

### Risk Classification
- Critical: Core to application, no alternatives, high exposure
- High: Significant functionality, limited alternatives
- Medium: Useful functionality, alternatives available
- Low: Convenience functionality, easily replaced

Organizations with strong TPRM programs should extend their frameworks to cover open source while adapting assessment criteria to the open source context.

Relationship to Vulnerability Management¶

Vulnerability management programs identify, prioritize, and remediate vulnerabilities across an organization's technology environment. Supply chain vulnerabilities—CVEs in dependencies—are a significant input to vulnerability management.

Workflow integration:

Supply chain vulnerability data should flow into existing vulnerability management processes:

Dependency Scanning → Vulnerability Discovery → Triage/Prioritization → 
Remediation Assignment → Fix Implementation → Verification → Closure

This workflow mirrors traditional vulnerability management. The key integration points are:

Discovery: SCA tools discover vulnerabilities in dependencies, feeding findings into the central vulnerability management system
Enrichment: Findings are enriched with context—affected applications, deployment status, exploitability
Prioritization: Supply chain vulnerabilities are prioritized using the same framework as other vulnerabilities (CVSS, EPSS, SSVC)
Assignment: Remediation is assigned to appropriate owners (application teams, platform teams)
Tracking: Remediation is tracked against SLAs in the same system as other vulnerabilities
Reporting: Supply chain vulnerabilities appear in vulnerability management dashboards and reports

Tooling integration example:

┌──────────────┐     ┌─────────────────┐     ┌──────────────────┐
│  Snyk/Grype  │────►│   DefectDojo/   │────►│  Jira/ServiceNow │
│  (SCA Tool)  │     │   Nucleus       │     │   (Ticketing)    │
└──────────────┘     │  (Aggregation)  │     └──────────────────┘
                     └─────────────────┘
                            │
                            ▼
                     ┌─────────────────┐
                     │   Dashboards/   │
                     │   Reporting     │
                     └─────────────────┘

Tools referenced: Snyk, Grype, DefectDojo, Nucleus

Most SCA tools provide integrations with common vulnerability management platforms. Leverage these integrations rather than treating supply chain vulnerabilities as separate from other vulnerability types.

Differentiation considerations:

While integration is valuable, supply chain vulnerabilities have unique characteristics:

Transitive dependencies: Vulnerabilities may exist in dependencies of dependencies, complicating remediation
Upstream fixes: Unlike infrastructure vulnerabilities, you often cannot patch directly; you wait for upstream fixes
Version constraints: Upgrading may introduce breaking changes or conflicts with other dependencies
False positives: Not all CVEs in dependencies are exploitable in your context

Vulnerability management processes should accommodate these characteristics through appropriate triage criteria and remediation workflows.

Relationship to Incident Response¶

Incident response programs handle security events, from detection through containment, eradication, recovery, and lessons learned. Supply chain incidents—compromised dependencies, malicious packages, upstream breaches—require incident response capabilities but may need specialized playbooks.

Playbook integration:

Organizations should extend their incident response playbook library to cover supply chain scenarios:

Scenario	Key Differences from Standard IR
Compromised dependency in production	Scope assessment requires SBOM; remediation may require upstream fix or replacement
Malicious package detected before deployment	Focus on build pipeline containment; assess whether production was ever affected
Upstream project compromise	Coordinate with external parties; monitor for downstream impacts
Supply chain attack on CI/CD	Build infrastructure may be attack target, not just application

Integration points with IR program:

Detection: Supply chain monitoring tools should feed into security monitoring and alerting infrastructure
Triage criteria: IR triage procedures should include supply chain-specific questions (Is this component in production? What version? What access does it have?)
Containment procedures: Playbooks should address dependency-specific containment (blocking package versions, rolling back deployments)
Communication templates: Notification templates should cover supply chain scenarios (customer notification of dependency compromise)
Evidence collection: Forensic procedures should include SBOM collection, build log preservation, and dependency tree analysis

We recommend adding supply chain scenarios to tabletop exercises. Many organizations have never practiced responding to a dependency compromise; the first time should not be during an actual incident.

Avoiding Duplication and Filling Gaps¶

Integration requires understanding where existing programs already address supply chain concerns and where gaps remain.

Gap analysis approach:

Inventory existing capabilities: Document what your current security programs do that relates to supply chain security
Map to supply chain security requirements: Compare existing capabilities against a comprehensive supply chain security framework (e.g., SLSA, NIST SSDF)
Identify overlaps: Where multiple programs address the same requirement, clarify ownership and eliminate duplication
Identify gaps: Where no program addresses a requirement, assign ownership and develop capability

Common gaps discovered:

Gap	Often Missing Because
SBOM generation and management	Not part of traditional security programs
Build provenance verification	New requirement without existing home
Dependency evaluation criteria	Falls between AppSec and TPRM
Package registry security	Often assumed to be "someone else's problem"
Maintainer security practices	No internal program covers external parties

Common duplications to resolve:

Duplication	Resolution Approach
Multiple SCA tools	Consolidate to primary tool with clear owner
Dependency scanning in AppSec and TPRM	Define single owner, share data
Vulnerability tracking in multiple systems	Feed all findings into central system
Incident response for supply chain vs. general	Integrate into unified IR program with specialized playbooks

Shared Tooling and Data¶

Effective integration often requires tooling consolidation and data sharing across programs.

Tooling consolidation opportunities:

Tool Category	Integration Opportunity
SCA scanning	Consolidate to single primary tool; avoid multiple tools reporting same vulnerabilities differently
Vulnerability tracking	Route all vulnerability data (infrastructure, application, supply chain) to common platform
SBOM management	Centralize SBOM storage for access by AppSec, IR, compliance
Developer tooling	Integrate supply chain checks into existing IDE plugins and CI/CD tools

Data sharing requirements:

SBOM data: Needed by vulnerability management, incident response, compliance
Vulnerability findings: Needed by vulnerability management, risk reporting, developer teams
Dependency metadata: Needed by TPRM, compliance (licensing), architecture review
Remediation status: Needed by vulnerability management, executive reporting, audit

Data architecture considerations:

┌─────────────────────────────────────────────────────────────┐
│              Central Supply Chain Data Store                │
│  (SBOMs, Dependency Metadata, Scan Results, Provenance)     │
└─────────────────────────────────────────────────────────────┘
        │              │              │              │
        ▼              ▼              ▼              ▼
   ┌─────────┐   ┌─────────┐   ┌──────────┐   ┌──────────┐
   │ AppSec  │   │  VulnMgt │   │   IR     │   │ Compliance│
   │ Program │   │ Program  │   │ Program  │   │ Program   │
   └─────────┘   └─────────┘   └──────────┘   └──────────┘

Sharing data avoids situations where each program maintains its own incomplete view of supply chain risk. Central data stores—whether purpose-built or federated through APIs—enable each program to access what it needs.

Recommendations¶

We recommend the following integration practices:

Map existing capabilities first: Before building new supply chain security capabilities, inventory what your existing programs already provide. Many organizations discover they have more coverage than they realized—or identify unexpected gaps.
Extend AppSec for supply chain: For most organizations, expanding the AppSec program to cover supply chain security is more effective than creating a parallel program. AppSec already owns the CI/CD pipeline and has relationships with development teams.
Adapt TPRM for open source: Apply third-party risk management principles to open source, but adapt assessment criteria for the different relationship model. Do not force-fit enterprise vendor assessment frameworks onto individual maintainers.
Unify vulnerability management: Route supply chain vulnerabilities through your existing vulnerability management process. Treat dependency CVEs the same as other vulnerabilities for prioritization, tracking, and reporting.
Add supply chain playbooks to IR: Extend your incident response program with supply chain-specific playbooks. Practice these scenarios through tabletop exercises before you face them in production.
Consolidate tooling: Avoid multiple tools reporting the same issues differently. Consolidate to primary tools with clear ownership and integrate them into common data platforms.
Share data across programs: Establish data sharing mechanisms so that AppSec, vulnerability management, TPRM, IR, and compliance all work from consistent information.

Integration is not a one-time activity. As your supply chain security program matures, revisit integration points. What made sense during initial implementation may need adjustment as capabilities and organizational structures evolve.