Defense & Intelligence · Moraph software

Software Bill of Materials (SBOM) Watchtower

Know what is inside every piece of software before it enters your environment

Book a demonstrationRequest a technical briefingFactsheet

Overview

What you are buying

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.

  • Compiled software arrives without a reliable list of the components inside it
  • Nested dependencies hide vulnerable or prohibited components several layers down
  • Answering "are we affected?" after a new vulnerability takes a manual search
  • Approval decisions and their evidence are hard to produce for assessors

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

Requirements it supports

Executive Order 14028, Improving the Nation's CybersecurityNIST SP 800-218, Secure Software Development Framework (SSDF)NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management PracticesNTIA, The Minimum Elements for a Software Bill of MaterialsSection 889 of the FY2019 John S. McCain National Defense Authorization Act (FAR 52.204-25)DoD Instruction 8510.01, Risk Management Framework for DoD Systems

The product supports these requirements; meeting them remains your organization’s responsibility.

See how it works

A short walkthrough

Illustrative screens with fictional sample data. They show the workflow, not any client’s data or configuration, and the layout of the product itself differs. A live demonstration uses the product with sample data.

  1. Step 1

    The intake queue

    Every package entering the environment appears in one queue, with its supplier, program and analysis result.

    PackageVersionSupplierProgramResultStatus
    Example Telemetry Agent4.2.1Example Supplier A (fictional)Program AlphaHeld: known exploited vulnerabilityIn review
    Example Map Server11.0.3Example Supplier B (fictional)Program BravoAdmitAwaiting approval
    Example Logging Library2.17.2Open sourceSoftware factoryAdmitReleased
    Example Firmware Bundle7.5Example Supplier C (fictional)Program CharlieHeld: prohibited supplier ruleIn review
    Example Desktop Client3.0.0Example Supplier A (fictional)Program AlphaAnalyzingQuarantined
    Every package entering the environment appears in one queue, with its supplier, program and analysis result.

  2. Step 2

    What is inside a package

    Watchtower shows the components it found, how deep they sit, and where they differ from the supplier's SBOM.

    Example Telemetry Agent 4.2.1 · Example Supplier A (fictional)

    Components found
    312
    Supplier SBOM
    CycloneDX, 297 components
    Not in supplier SBOM
    15 components
    Deepest dependency
    6 layers
    Not identified
    4 binaries
    Signature
    Valid, matches supplier's published key

    Findings

    • Example logging component 2.14.0 nested in a bundled plugin, listed as known exploited
    • 15 components bundled but not declared by the supplier
    • 4 binaries could not be matched to a known component
    Watchtower shows the components it found, how deep they sit, and where they differ from the supplier's SBOM.

  3. Step 3

    Policy results

    Each policy is applied and its result recorded with the rule that produced it.

    PolicyRuleResultDetail
    Known exploited vulnerabilitiesNone permittedFail1 component
    Critical vulnerabilitiesCondition requiredFail2 components
    Supplier listProgram list v14PassSupplier approved
    Code signingSignature requiredPassValid
    Undeclared componentsSupplier response requiredFail15 components
    Each policy is applied and its result recorded with the rule that produced it.

  4. Step 4

    The decision

    The analyst recommends and a separate approver decides, with the evidence and any conditions recorded.

    Example Telemetry Agent 4.2.1

    1. Package received from supplier portalSubmitter
    2. Analysis complete, held on two policiesWatchtower
    3. Supplier asked to explain undeclared componentsSupply chain analyst
    4. Supplier provides updated build 4.2.2Submitter
    5. Recommendation: reject 4.2.1, analyze 4.2.2Supply chain analyst
    6. Recommendation approvedApprover
    The analyst recommends and a separate approver decides, with the evidence and any conditions recorded.

  5. Step 5

    Are we affected?

    When a new vulnerability is published, one search shows every admitted package and system that contains the component.

    PackageComponentProgramSystemsOwner notifiedStatus
    Example Map Server 11.0.3Example parser 1.8.0Program Bravo6YesRemediation open
    Example Report Builder 2.4Example parser 1.8.0Program Alpha2YesSupplier VEX: not affected
    Example Desktop Client 2.9Example parser 1.7.4Program Charlie14YesRemediation open
    When a new vulnerability is published, one search shows every admitted package and system that contains the component.

  6. Step 6

    Conditions coming due

    Conditional admissions return for review on the date set, with their owner and conditions in view.

    Example Map Server 11.0.3 · Conditional admission

    Condition
    Supplier to deliver fixed build
    Compensating measure
    Service not exposed outside enclave
    Owner
    Program Bravo
    Approved by
    Approver
    Review date
    Due this week

    History

    • Admitted with condition after review
    • Supplier response recorded
    • Reminder sent to program owner
    Conditional admissions return for review on the date set, with their owner and conditions in view.

Workflows

The principal workflows

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

    • Package submitted by a program office, supplier or pipeline
    • Hashes and signatures recorded and checked against the supplier's published values
    • Supplier SBOM in SPDX or CycloneDX attached, if provided
    • Package placed in a quarantine area pending analysis
    • Submitter and program recorded for every package

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

    • Archives, containers and installers unpacked layer by layer
    • Binary composition analysis identifies components and versions
    • A generated SBOM is produced for the package
    • Differences from the supplier's SBOM are listed for review
    • Components that could not be identified are flagged rather than ignored

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

    • Components matched against the National Vulnerability Database and the CISA Known Exploited Vulnerabilities catalog
    • Supplier and provenance policies applied from the lists your program maintains
    • Each policy result recorded with the rule that produced it
    • Package recommended to admit, admit with conditions, or hold

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

    • Analyst reviews findings and writes a recommendation
    • Approver admits, admits with conditions, or rejects the package
    • Admitted package released to the approved repository with its SBOM
    • New vulnerability data re-checked against every stored SBOM
    • Affected packages and owning programs notified for action

Roles and permissions

Who does what in the product

Each role below is a starting point. During implementation we set them up to match your teams, and every action anyone takes is recorded in the audit trail.

Submitter

Program office engineer, supplier delivery contact, DevSecOps pipeline (service account)

Brings software into the intake process with the information needed to analyze it.

Sees

  • Their own submissions and their status
  • The overall result for each submission and any request for information
  • Supplier SBOMs and VEX documents they uploaded

Does

  • Submits packages with version, supplier and program details
  • Uploads supplier SBOMs and VEX statements
  • Answers requests for information from analysts
  • Withdraws a submission before a decision is made

Cannot

  • See detailed findings for other programs' packages
  • Release a package from quarantine
  • Change policies or results
Approvals
Nothing they submit is released until a decision is recorded by an approver or by a policy your program has approved for automatic release.
Notified about
Analysis complete, requests for information, and decisions on their submissions.

Supply chain analyst

Supply chain risk analyst, software assurance analyst, cyber security analyst

Reviews findings on held packages and recommends what should happen to them.

Sees

  • Held and admitted packages within their programs, with all findings
  • Generated and supplier SBOMs and the differences between them
  • Policy results and the rules that produced them
  • Affected-systems searches for new vulnerabilities

Does

  • Reviews findings and component trees
  • Requests information from suppliers and submitters
  • Writes a recommendation to admit, admit with conditions or reject
  • Records supplier VEX statements and their assessment of them
  • Runs affected-systems searches and notifies program owners

Cannot

  • Approve their own recommendation
  • Change policies or supplier lists
  • Edit analysis results
Approvals
Every recommendation goes to a designated approver.
Notified about
Packages held for review, supplier responses, and new vulnerabilities affecting admitted packages.

Approver

Authorizing official's designated representative, information system security manager, software assurance lead

Makes the decision on held packages and accepts any risk in a conditional admission.

Sees

  • All packages, findings and recommendations in their scope
  • Conditional admissions and waivers with their review dates
  • Policy override history

Does

  • Admits, admits with conditions, or rejects packages
  • Sets conditions, owners and review dates
  • Approves policy overrides with a recorded justification
  • Extends or revokes conditional admissions
  • Approves policy changes proposed by the policy owner

Cannot

  • Approve a recommendation they wrote themselves
  • Edit or delete audit records
  • Remove a policy result from the record
Approvals
Decisions are theirs; policy changes they propose themselves need a second approver.
Notified about
Recommendations awaiting decision, conditions coming due, and overrides requested.

Policy owner

Supply chain risk management lead, cyber policy officer

Keeps the vulnerability, supplier, license and provenance policies current with program guidance.

Sees

  • All policies, their versions and change history
  • Policy results across packages
  • Overrides and the justification for each

Does

  • Proposes changes to policies and supplier lists
  • Tests a proposed policy against stored packages to see its effect
  • Retires outdated rules
  • Prepares policy documentation for assessors

Cannot

  • Put a policy change into effect without an approver
  • Decide on individual packages
  • Edit past results
Approvals
Every policy change is approved by an approver before it takes effect.
Notified about
Approval decisions on their changes and repeated overrides of the same rule.

Program owner

Program manager, system owner, chief engineer

Knows what software their program depends on and acts when a component becomes a risk.

Sees

  • Packages and SBOMs for their program
  • Conditions assigned to their program
  • New vulnerability notices affecting their systems

Does

  • Acknowledges vulnerability notices and assigns remediation
  • Records remediation progress and supplier responses
  • Requests extensions to conditions with justification
  • Exports SBOMs for their program's documentation

Cannot

  • Admit or reject packages
  • See other programs' findings
  • Change policies
Approvals
Extensions they request are decided by an approver.
Notified about
New vulnerabilities in their packages, conditions coming due, and decisions on their requests.

Assessor (read-only)

Security control assessor, inspector general staff, internal auditor

Reviews supply chain decisions and their evidence without being able to change anything.

Sees

  • Packages, SBOMs, findings and decisions within the scope granted
  • Policies and their change history
  • The audit trail

Does

  • Searches and reads records within their scope
  • Exports records and reports, with each export logged
  • Leaves review notes where enabled

Cannot

  • Change, approve or delete anything
  • Keep access after it expires
Approvals
Their access is approved by an approver or administrator, with a scope and an end date.
Notified about
Nothing by default.

Administrator

Application administrator, system administrator

Manages users, roles, intake points and integrations without deciding on packages.

Sees

  • Users, roles and program assignments
  • Intake points, repository and pipeline connections
  • The record of permission changes

Does

  • Adds and removes users or maps them from single sign-on groups
  • Configures intake points and connections
  • Loads vulnerability data updates on disconnected networks
  • Runs access review reports

Cannot

  • Approve or reject packages
  • Change policies
  • Grant themselves an approver role without a second administrator
Approvals
Role changes that grant approval rights are confirmed by an existing approver.
Notified about
Failed vulnerability data updates, connection failures and access reviews coming due.

Permissions at a glance

ActionSubmitterAnalystApproverPolicy ownerProgram ownerAssessorAdmin
Submit packagesOwn work onlyFullFullNo accessOwn work onlyNo accessNo access
View findings and SBOMsOwn work onlyFullFullView onlyOwn work onlyView onlyNo access
Request supplier informationNo accessFullFullNo accessOwn work onlyNo accessNo access
Recommend a decisionNo accessFullFullNo accessNo accessNo accessNo access
Admit or reject a packageNo accessNo accessApprovesNo accessNo accessNo accessNo access
Override a policy resultNo accessNo accessApprovesNo accessNo accessNo accessNo access
Change policies and supplier listsNo accessNo accessApprovesFullNo accessNo accessNo access
Run affected-systems searchNo accessFullFullView onlyOwn work onlyView onlyNo access
Manage conditions and remediationNo accessView onlyApprovesNo accessOwn work onlyView onlyNo access
View audit trailNo accessNo accessView onlyView onlyNo accessView onlyView only
Manage users and intake pointsNo accessNo accessApprovesNo accessNo accessNo accessFull
  • Full
  • Own work only
  • Approves
  • View only
  • No access

How access is controlled

  • Two-person rules are built in: the analyst who recommends a decision cannot approve it, and policy changes need an approver other than the person who proposed them.
  • Roles are configured with you during implementation and can be limited by program, so a program sees its own packages and findings and not another program's.
  • Every permission change is recorded in the audit trail with who made it and when, and access review reports list each person's roles for periodic certification.
  • Pipelines submit through service accounts with the submitter role only. Assessors get temporary read-only access with a defined scope and an end date, rather than shared accounts.

Features

What it does

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

How it connects to your systems

Connects toHowWhat flows
Artifact repositoriesPackages are pulled from, and released to, the artifact repositories your software factory uses, such as JFrog Artifactory, Sonatype Nexus or a container registry.In: packages for intake. Out: admitted packages with their SBOM and decision record.
CI/CD pipelinesPipelines submit builds to Watchtower and wait for a result before promoting them.In: build artifacts and metadata. Out: admit, hold or reject result.
Vulnerability sourcesThe National Vulnerability Database and the CISA Known Exploited Vulnerabilities catalog are imported on a schedule; in disconnected environments they are loaded by approved transfer.In: vulnerability records and known-exploited status.
Supplier SBOMs and VEXSuppliers upload SBOMs and VEX statements through a supplier portal or with the package.In: SPDX or CycloneDX SBOMs and VEX documents.
Supplier and provenance listsYour program's lists of prohibited and approved suppliers, and any provenance data you hold, are loaded and versioned.In: supplier lists and provenance records maintained by your program.
System inventoryYour configuration management or asset inventory links admitted packages to the systems that run them.In: systems and installed packages. Out: affected systems for a vulnerability.
Single sign-onStaff sign in through your identity provider (SAML or OpenID Connect), including smart-card authentication where your provider supports it.In: user identity and group membership for role assignment.
Work APIPackage, finding and decision data is available to your reporting and risk tools through the Moraph Work API.Out: packages, SBOMs, findings and decisions.

Each integration is confirmed in discovery and specified in the design. See how an engagement progresses.

Security and privacy

How your data is protected

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.

Company-wide controls, independent audits (SOC 2 Type II and ISO/IEC 27001) and data residency are described in our Trust Center, where you can request the evidence pack.

Reporting

What you can report on

10 standard reports, grouped by who uses them. Each shows who it is for, how it can be broken down, how it is delivered and what it is used for. The data behind them is also available to your own reporting tools.

Operational

Intake queue by age

For supply chain analysts and approvers

Every package in quarantine or held for review, with its age, program, supplier and the reason it is held.

Break down by
Program, Supplier, Hold reason, Age band
Delivered as
Live dashboard; CSV export
Used for
Keeping held packages moving and seeing where suppliers are slow to respond.

Affected systems for a vulnerability

For analysts, program owners and approvers

For a chosen vulnerability or component, every admitted package and system that contains it, with notification and remediation status.

Break down by
Program, Package, Component version, Remediation status
Delivered as
On request in the product; CSV and PDF export
Used for
Answering "are we affected?" and tracking the response.

Conditions and waivers due

For approvers and program owners

Conditional admissions and waivers with their conditions, owners and review dates.

Break down by
Program, Owner, Review date, Condition type
Delivered as
Live dashboard; scheduled email
Used for
Making sure conditions are reviewed when they are due rather than forgotten.

Management

Intake outcomes

For program leadership and the authorizing official

Packages received, admitted, conditionally admitted, rejected and withdrawn over a period.

Break down by
Program, Supplier, Period, Outcome
Delivered as
Live dashboard; PDF; CSV export
Used for
Reporting on the software supply chain program and the decisions it is making.

Supplier SBOM quality

For program offices and contracting staff

For each supplier, whether SBOMs were provided, which format, and how often they differed from the generated SBOM.

Break down by
Supplier, Program, Format, Period
Delivered as
Live dashboard; CSV export
Used for
Raising SBOM quality with suppliers and informing contract requirements.

Open vulnerabilities in admitted software

For program owners and leadership

Known vulnerabilities in admitted packages that remain open, with their severity, known-exploited status and owner.

Break down by
Program, Severity, Known exploited, Age
Delivered as
Live dashboard; scheduled email
Used for
Prioritizing remediation across programs.

Assessment and audit

Decision record

For assessors, inspectors general and approvers

For a package or period, every finding, recommendation, decision and condition, with who made each and when.

Break down by
Package, Decision, Approver, Date range
Delivered as
On request in the product; PDF and CSV export
Used for
Providing evidence of supply chain controls for assessments.

Policy change history

For policy owners, approvers and assessors

Every change to policies and supplier lists, its test result against stored packages, and who proposed and approved it.

Break down by
Policy, Change date, Approver
Delivered as
Live view; PDF and CSV export
Used for
Showing that policy changes were tested and approved.

Overrides

For approvers and assessors

Every override of a policy result with its justification and approver.

Break down by
Policy, Program, Approver, Period
Delivered as
Live view; CSV export
Used for
Reviewing whether overrides are used as intended.

SBOM export

For program owners and assessors

The SBOMs for a program or system in SPDX or CycloneDX, with the decision record for each package.

Break down by
Program, System, Format
Delivered as
On request; SPDX and CycloneDX files
Used for
Supplying SBOMs for authorization packages and to partners who need them.

Exports, access and evidence

  • Every report can be exported to CSV, and summary and evidence reports to PDF. Reports can be scheduled to arrive by email for the people entitled to see them.
  • Each report can be filtered by program and the filters saved, so a program owner sees their own picture and leadership sees the whole.
  • Package, SBOM, finding and decision data is available through the Moraph Work API for your own risk and reporting tools.
  • Reports respect each viewer's role and program scope; assessors can be given read-only access to reports and the audit trail.
  • Assessment reports can be run as of a past date and give the same result each time. Running and exporting a report is itself recorded in the audit trail.

Deployment

Where and how it runs

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 controls, independent audits and data residency are set out in our Trust Center. Engagement models and what drives a quotation are on Working with Moraph.

Implementation

What a rollout involves

The general phases are on Working with Moraph. For this product, they involve the following.

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.

Limitations

What it does not do

Worth knowing before you evaluate it.

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

Evaluation checklist

What to test in a demonstration or pilot

Questions worth putting to us, and to any other vendor you are considering.

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

Questions

Frequently asked questions

Does Watchtower decide which countries or suppliers are prohibited?

No. Your program supplies those lists and the provenance data behind them. Watchtower applies them consistently and records the result.

What if a supplier does not provide an SBOM?

Watchtower generates one from the package itself, and records that no supplier SBOM was provided so you can follow up with the supplier.

Can it run on a network with no internet access?

Yes. It can be installed in your own disconnected environment, with vulnerability data and updates loaded through your approved transfer process.

Is Watchtower accredited for classified networks?

Moraph does not claim accreditation. Where you install it on a classified network, it is authorized and operated under your authority, and we provide control mappings and documentation to support your process.

How is it priced?

As a subscription, usually measured by the number of programs or the volume of software analyzed, with implementation charged separately. See Working with Moraph for what drives a quotation.

Is there an accessibility conformance report?

Ask for one through the procurement request form at /how-to-buy/request, naming the version you are evaluating.

Next steps

Evaluate Software Bill of Materials (SBOM) Watchtower

Book a demonstration

See the product working with sample data, focused on your workflows.

Request a demonstration

Request a technical briefing

Architecture, integrations, security and hosting, with our engineers and your technical team.

Request a briefing

Factsheet

This page on two sides, to share with colleagues or add to your evaluation file.

Open the factsheet

Buying through a formal procurement? See How to buy for purchasing routes, accessibility conformance reports and company information. Documentation: Software Bill of Materials (SBOM) Watchtower guides on docs.moraph.com (getting started and security guides are public; setup, administration and integration guides are for client accounts). Support: Software Bill of Materials (SBOM) Watchtower support guide.

Related products