Software Bill of Materials (SBOM) Watchtower

SBOM Watchtower checks software at the point of intake: it collects or generates a software bill of materials for each package, decomposes binaries and containers to find nested dependencies, and matches every component against known vulnerabilities and your own supplier and provenance policies. Packages that break a policy are held for a decision by your authorizing staff rather than passing through unseen. Each decision keeps its evidence, so your program can show what was admitted, why, and what changed when a new vulnerability was published.

The problem it solves

Defense programs take in software from primes, subcontractors, open-source projects and commercial vendors, often as compiled binaries with little documentation of what they contain. A vulnerable library several layers down can sit unnoticed until it is exploited, and when a new vulnerability is announced, teams spend days working out which systems are affected. Supplier SBOMs arrive in different formats or not at all, provenance requirements are checked by hand, and the record of why a package was approved is spread across tickets and email.

Who it’s for

• Software supply chain and cyber security teams in defense programs and commands
• Authorizing officials and information system security managers who approve software for use
• Program offices that receive software deliveries from primes and subcontractors
• DevSecOps platform teams running software factories and artifact repositories
• Assessors and inspectors general who need evidence of supply chain controls

1. IntakeSoftware enters through a single intake point: an upload, a delivery from a supplier portal, or a pull from your artifact repository. Each package is registered with its source, version and the supplier's own SBOM if one was provided.
2. DecomposeWatchtower unpacks installers, archives, containers and firmware images and analyzes the binaries inside to identify components and their versions, including dependencies bundled several layers deep. Its findings are compared with the supplier's SBOM.
3. EvaluateEvery component is matched against vulnerability sources and your policies: known exploited vulnerabilities, license rules, prohibited suppliers and provenance requirements your program defines. The result is a recommendation, not a final decision.
4. Decide and watchA reviewer and an approver decide what happens to held packages. Admitted packages stay under watch: when a new vulnerability is published, Watchtower lists every admitted package and system that contains the affected component.

Binary decomposition

Installers, archives, container images and firmware are unpacked and their binaries analyzed to identify the components inside, including bundled libraries.

SBOM generation and comparison

An SBOM is generated for every package and compared with the supplier's, so missing or undeclared components are visible.

Standard formats

Reads and writes SPDX and CycloneDX, and records the NTIA minimum elements for each component.

Vulnerability matching

Components are matched against the National Vulnerability Database and the CISA Known Exploited Vulnerabilities catalog, with VEX statements from suppliers recorded alongside.

Supplier and provenance policies

Rules your program defines, such as prohibited suppliers, required signatures or provenance attestations, are applied to every package and every component where origin data exists.

Quarantine and release

Packages wait in quarantine until a decision is recorded, then are released to your approved repository with their SBOM attached.

Two-person decisions

The analyst who reviews a held package cannot also approve it; admitting with conditions or overriding a policy needs a designated approver.

Continuous watch

Stored SBOMs are re-checked when new vulnerability data arrives, and the programs that own affected packages are told.

Affected-systems search

Search every admitted package for a component and version, and see which programs and systems use it.

Signature and hash checks

Package hashes and code-signing signatures are checked against the values the supplier publishes, and mismatches are flagged.

Exceptions and waivers

Conditional admissions carry their conditions, owner and review date, and come back for review when that date arrives.

Evidence trail

Every intake, finding, decision and release is recorded with the person and time, ready for assessors.

Submitter

Submits software packages and supplier SBOMs, and sees the status of their own submissions

Supply chain analyst

Reviews findings for held packages and recommends a decision

Approver

Admits, conditionally admits or rejects packages, and approves policy overrides

Policy owner

Maintains supplier, provenance and vulnerability policies, subject to approval

Program owner

Sees the packages their program uses and acts on new vulnerability notices

Assessor (read-only)

Views packages, findings, decisions and the audit trail without changing them

Artifact repositories

Packages are pulled from, and released to, the artifact repositories your software factory uses, such as JFrog Artifactory, Sonatype Nexus or a container registry.

CI/CD pipelines

Pipelines submit builds to Watchtower and wait for a result before promoting them.

Vulnerability sources

The National Vulnerability Database and the CISA Known Exploited Vulnerabilities catalog are imported on a schedule; in disconnected environments they are loaded by approved transfer.

Supplier SBOMs and VEX

Suppliers upload SBOMs and VEX statements through a supplier portal or with the package.

Supplier and provenance lists

Your program's lists of prohibited and approved suppliers, and any provenance data you hold, are loaded and versioned.

System inventory

Your configuration management or asset inventory links admitted packages to the systems that run them.

Single sign-on

Staff sign in through your identity provider (SAML or OpenID Connect), including smart-card authentication where your provider supports it.

Work API

Package, finding and decision data is available to your reporting and risk tools through the Moraph Work API.

Single sign-on

Staff sign in through your identity provider, so your authentication and multi-factor policies apply.

Role-based access

What each person can see and do follows their role; reviewing a package is separate from approving it.

Isolated analysis

Packages are unpacked and analyzed in an isolated area and are never executed as part of analysis.

Encryption and keys

Client data is encrypted, with keys Moraph staff cannot use without explicit, time-bound authorization.

Complete audit trail

Every intake, view, decision, override and release is logged with the person and time, and cannot be edited.

US-only hosting and support

Hosted in the United States region only; support tickets for defense clients are handled only by US citizens with active clearances, and work on classified networks happens under your authority.

Moraph cloud, US region

Hosted and operated by Moraph in the United States region, for unclassified software intake.

Client-hosted

Installed in your own environment, including disconnected and classified networks, where it is operated under your authority and your authorization process.

In your software factory

Deployed alongside your DevSecOps pipelines and repositories so builds are checked before promotion.

Intake design

We agree where software enters your environment, which repositories and pipelines connect, and who submits on behalf of each program.

Policy setup

Your vulnerability thresholds, license rules and supplier and provenance policies are configured from the lists and guidance your program provides. Moraph does not decide which suppliers are prohibited.

Baseline of existing software

Software already in use is run through Watchtower to produce a baseline of SBOMs and findings, reviewed with your team before enforcement starts.

Workflow and roles

Review queues, approval steps, condition types and roles are set to match your procedures and authorization boundaries.

Disconnected operation

Where Watchtower runs on a network without internet access, we set up the approved process for loading vulnerability data and updates.

Training and enforcement

Submitters, analysts and approvers are trained on their own workflows, and enforcement is switched on for each intake point by agreement.

• Binary analysis cannot identify every component. Heavily modified, obfuscated or custom-built code may not match known components, and Watchtower reports what it could not identify rather than assuming it is safe.
• Country-of-origin and supplier restrictions are applied from the lists and provenance data your program supplies. Watchtower does not determine on its own where a component was written or by whom.
• Vulnerability results depend on the vulnerability sources loaded; on disconnected networks they are only as current as the last approved update.
• Watchtower recommends; people decide. Admitting, conditionally admitting or rejecting a package is a decision made by your designated approvers.
• It does not run or test the behavior of software, and it is not a malware sandbox or an antivirus product.
• It does not grant an authority to operate. It produces evidence that supports your authorization process.
• Moraph does not claim accreditation for any classified environment; use on classified networks is under your authority.
• Remediating a vulnerable component is the job of the supplier or the program; Watchtower tracks it but does not patch software.

• Submit a few packages you already use, including at least one container image and one installer, and review the components found
• Compare Watchtower's generated SBOM with a supplier SBOM you hold
• Search for a component you know is present and check every package that contains it appears
• Load a sample supplier list and confirm the policy result is recorded with the rule that produced it
• Work a held package from finding to approved decision and review the evidence produced
• Confirm role separation: who can review, approve and override