Supply Chain Security

Your system is only as secure as the things it trusts.

Modern systems lean on third-party services, dependencies, and platforms that sit outside your code but well inside your trust boundary. ThreatModeler^® Nexus™ models those relationships as part of the design, so the risk you inherit is visible alongside the risk you build.

Book a demo How it works

The risk you inherit is still the risk you own.

Where the trust boundary really sits

The dependency you didn't write is part of your design.

A system's attack surface extends through every service and component it relies on. Securing only your own code leaves the trust you've placed in everything else unexamined.

"We secure what we build, but our systems depend on services and components we don't control."

Model the whole picture. The System Mapping Agent captures external services and dependencies as part of the system, so the trust placed in each one is represented in the threat model rather than assumed.

"We can scan our dependencies for known issues, but that doesn't tell us where a compromise would actually reach."

Reason about the trust boundaries. Because the model is anchored in design, ThreatModeler Nexus shows where a trusted dependency sits relative to your data and controls, and what is missing to contain it.

"The dependencies change constantly, so any picture we draw is out of date almost immediately."

Keep the picture current. The Secure Design Graph updates as systems change, so the model reflects the relationships in place now, not the ones from the last review.

Design-level visibility

See the risk you take on, not just the code you wrote.

ThreatModeler Nexus is a threat modeling platform first: it shows what could go wrong in a system so you can mitigate it. That system includes everything it depends on, so external trust is part of the analysis.

Mapped

Dependencies in the model

External services and components are captured as part of the system map, so the trust extended to each one is explicit instead of implied.

Grounded

Anchored in design

The Secure Design Graph holds the relationships and context around each dependency, so analysis reflects how the system actually relies on it.

Governed

Consistent and current

Versioning and a full audit trail keep the picture defensible, and a deterministic framework keeps the AI working on your approved content.

See the Secure Design Graph

Regulatory context

Supply chain security is now a compliance requirement.

Supply chain risk has moved from a best practice to an explicit regulatory obligation. Executive Order 14028 (May 2021) required federal agencies and their software suppliers to adopt zero-trust architecture and secure software development practices, including transparency about components and dependencies. The NCSC (UK) updated supply chain cybersecurity guidance in October 2022. The EU NIS2 Directive extended supply chain risk management obligations to essential and important entities across Europe.

SBOM — Software Bill of Materials: is the emerging standard for supply chain transparency, requiring organizations to enumerate and account for the components their software contains. ThreatModeler Nexus models dependencies as part of the architecture, so the risk analysis follows the SBOM rather than having to be reconstructed from it.

See the Secure Design Graph

✓

SBOM-aware risk analysis. Model the components, dependencies, and third-party services that the SBOM enumerates, so threat analysis follows the inventory rather than trailing it.

✓

Executive Order 14028 alignment. Secure software development practices and supply chain transparency requirements for federal suppliers, addressed at the design level.

✓

NIS2 supply chain obligations. Essential and important entity requirements for third-party risk assessment, with evidence traceable to the design and the contractual relationship.

✓

NCSC supply chain guidance. The UK NCSC framework for assessing and managing supply chain cybersecurity risk, applied to the systems and relationships in your model.

✓

Audit-ready evidence. Every third-party risk decision traces to the architecture and the framework that requires it, with version history intact for when the question is asked in a review.

See what could go wrong, before it does.

Book a demo