Software Bill of Materials (SBOM) Watchtower

Principal workflows

• Intake: Software 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.
• Decompose: Watchtower 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.
• Evaluate: Every 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.
• Decide and watch: A 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.

Who uses it

• 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

Reporting

• Packages received, admitted, held and rejected by program and supplier
• Held packages by age and reason
• Affected packages and systems for a newly published vulnerability
• Conditional admissions and waivers coming due for review
• Differences between supplier SBOMs and generated SBOMs, by supplier
• Policy changes and overrides, for assessors

Features

• 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.

Integrations

• 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.

Deployment

• 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.

Security and privacy

• 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.

Limitations

• 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.

Next steps

Book a demonstration or a technical briefing at www.moraph.com/solutions/software-bill-of-materials-sbom-watchtower. Purchasing routes and company information: www.moraph.com/how-to-buy.