# SBOM and Vendor Dependency Disclosure Monitoring: See What Ships Inside the Software You Buy Source: PageCrawl.io Blog URL: https://pagecrawl.io/blog/sbom-vendor-dependency-disclosure-monitoring Published: 20 September, 2026 --- A critical vulnerability drops in a widely used compression library at 4pm on a Thursday. Farah, who runs product security at a 400-person manufacturer, can answer the question for her own code in about six minutes, because her build pipeline generates a bill of materials for every artefact her team ships. Then the executive question arrives: are we exposed through the eleven commercial products we bought? The building management platform, the ERP add-ons, the network appliances, the two on-premise analytics tools nobody has touched since the migration. For those, she has nothing but a purchase order and a support portal login. So she starts the same slow ritual as everyone else. She opens each vendor's third-party notices document, searches for the library name, and finds that several were last regenerated at some unstated point in the past, two list a version that has not shipped in years, and one vendor's SBOM portal now says the product family has moved to a different disclosure programme with different access terms. None of that was announced. That gap is the whole problem. Vendors increasingly do publish what is inside their software, in open source notices files, third-party disclosure documents, licensing appendices, and SBOM request portals. What they almost never do is tell you when that published inventory changes. Point a check at those pages and, instead of rediscovering the inventory in a panic during an advisory, you accumulate a dated record of what each vendor said was inside their product and when they changed the answer. ### What is an SBOM and why should a buyer watch the vendor's copy of it? An SBOM is a machine-readable inventory of the components inside a piece of software: the name of each component, its supplier, its version, and how the pieces depend on each other. As a buyer you care because that list determines your exposure to every third-party vulnerability, and because it changes with each release without any announcement. The reference definition comes from the US government. The [NTIA's software bill of materials programme](https://www.ntia.gov/page/software-bill-materials) published the minimum elements a usable SBOM should carry, including supplier name, component name, version, dependency relationships, the author of the SBOM data, and a timestamp. [CISA's SBOM work](https://www.cisa.gov/topics/information-communications-technology-supply-chain-security/sbom) carried that into practical guidance on generating, sharing, and consuming the documents. Read both before you argue with a vendor about what they owe you. The buyer's version of the problem is different from the producer's. If you build software, an SBOM is something you generate. If you buy software, it is something you are given, on the vendor's schedule and in the vendor's format. You have no build pipeline to re-run, so the freshness of your knowledge is exactly the freshness of your last look at their page. #### Why a stale answer is worse than no answer A component inventory you captured two years ago and never refreshed is actively dangerous, because it feels like an answer. It tells you version 1.2.11 of a library is present when the current release ships 1.3.1, or that a dependency you flagged as risky was removed when it was in fact renamed. Teams act on stale inventories with confidence and discover the gap during the incident. A monitored page gives you what a spreadsheet never does: a date attached to every version of the answer. ### Which vendor pages actually show what ships inside the software? Four page types carry the real signal: public third-party source and notices portals, per-product open source disclosure documents, licensing information appendices in vendor documentation, and SBOM request or distribution portals that state which products are covered and under what terms. Each is a normal web page that changes when the vendor updates it. #### Public third-party source and notices portals Large vendors run a central site listing the open source components shipped inside their products alongside licence text and source availability. [Microsoft's third-party source code site](https://thirdpartysource.microsoft.com/) is the best known example: you look up a product and a version, and the site tells you what third-party code is in it. [Siemens publishes a third-party software disclosure document](https://premiumservices.siemens.com/assets/ReadMe_OSS.html) covering the open source in its offerings, with licence conditions and copyright notices attached. These pages are the closest thing to a public component inventory for commercial software, and they get regenerated whenever the product changes. #### Per-product open source disclosure documents Below the central portals sit thousands of product-specific pages: an "open source licence acknowledgements" page for one appliance firmware, a "third-party notices" appendix in a documentation set, a NOTICE file linked from a release page. These are usually flat HTML or PDF, version-stamped, and updated when a release ships. They carry the actual version numbers, which the marketing-facing security pages never do. #### SBOM request and distribution portals Some vendors do not publish the SBOM itself but publish the rules for getting one. [Cisco's SBOM FAQ and request instructions](https://sec.cloudapps.cisco.com/security/center/resources/sbom-faq) are a good example: the page states which product categories are in scope, the delivery format, and the terms restricting who you may share the document with. When a vendor widens coverage to a product family you own, or narrows the sharing terms so you can no longer hand the document to an auditor or a subcontractor, the change happens on that page and nowhere else. #### Where component disclosure sits next to your other vendor monitors Component disclosure is one layer of a wider picture. If you already track [vendor trust centres and certification pages](/blog/vendor-trust-center-certification-monitoring), adding the disclosure pages fills the gap between "this vendor is certified" and "this specific build contains this specific library at this specific version." | Page type | What changes | Why it matters | Sensible check cadence | |-----------|--------------|----------------|------------------------| | Central third-party notices portal | Products added, component lists regenerated | Tells you what is inside a purchased product | Daily | | Per-product OSS disclosure document | Component versions bumped, entries added or removed | The only place version numbers appear | Daily | | SBOM request or portal policy page | Scope of covered products, format, sharing terms | Controls whether you can get and share the document | Daily | | Vendor security advisory index | New advisories referencing components | Confirms exposure the inventory implied | Every few hours | | Licensing information appendix | Licence of a component changes | Legal exposure, redistribution rights | Weekly | ### Why doesn't the vendor just email you when a component changes? Because component disclosure is a compliance artefact, not a communications channel. Vendors publish the document to satisfy licence obligations and procurement requirements, and almost none of them offer a subscribe button on it. Their notification programmes cover security advisories and product end-of-life, which are curated announcements, not the underlying inventory. There is a structural reason for this. A vendor's security advisory tells you about a vulnerability the vendor has decided to disclose, in a product they have decided is affected, on a timeline they control. The component list tells you what is present regardless of whether the vendor has finished their own analysis. In the first days of a widely exploited flaw, that difference is the entire game: the component page can tell you a product bundles the affected library while the vendor's advisory page still says "under investigation." There is also a process reason. These documents are regenerated by build tooling and published by release engineering, so nobody treats the update as an announcement. The file is overwritten, and if the previous version was not captured somewhere, the change is unrecoverable. #### No mainstream free tool does this for you Vulnerability scanners read the SBOMs you already possess. Procurement platforms store the documents you upload. Neither of them watches the vendor's public page and tells you it changed. That watching is a plain change-detection job, and it is the one piece nobody sells you as part of the software you bought. ### How do you set up SBOM and component disclosure monitoring in PageCrawl? Point a monitor at each vendor's disclosure page, use reader or text tracking so you get a readable diff of the component list rather than a screenshot comparison, check daily, and route alerts to the channel your security team actually reads. Setup for a first vendor takes a few minutes and the same pattern repeats for every product you own. 1. **Collect the exact URLs.** For each product in scope, find the page that shows the components, not the product page linking to it: the third-party notices document, the licensing appendix for your version, or the SBOM portal page stating coverage and terms. If the vendor publishes per-version documents, monitor the current version and add the new one when a major release lands. 2. **Add each URL and pick the tracking mode.** Reader mode suits long disclosure documents because it strips navigation and site chrome and compares the substance of the list. For portal pages where one paragraph of terms matters, text tracking on that region is tighter. For PDF documents, use PDF extraction so the text inside the file is compared rather than the file's metadata. 3. **Set the check frequency to daily for most pages.** These documents update on release cadence, not by the minute. Raise the frequency on pages tied to products you consider critical, so that during an active advisory you learn about a regenerated document within minutes on higher plans rather than at the end of the day. 4. **Choose notification channels that reach the responder.** PageCrawl delivers to email, Slack, Discord, Microsoft Teams, Telegram, and outbound webhooks. Route these into the channel where advisories already land, and send the webhook into a ticketing or SOAR workflow so a changed disclosure document opens a task instead of scrolling past in chat. 5. **Add keyword rules for the components you care about most.** Add keyword conditions on the libraries on your exposure list so a diff naming them is escalated while a formatting change is filed quietly. The same technique works for licence identifiers your legal team restricts. 6. **Add threshold rules to suppress trivial diffs.** Disclosure pages carry generated timestamps and document revision numbers that change without any component changing. Set a minimum change threshold and mark those regions as ignored after the first noisy alert. 7. **Turn on change history and screenshots.** The archived versions are the point: when an auditor or a customer asks what a vendor disclosed on a given date, you want a dated capture rather than a recollection. It is the same evidence trail described in our guide to [monitoring SaaS vendor terms of service changes](/blog/monitor-terms-of-service-changes-saas-vendors), applied to the technical inventory instead of the contract. 8. **Group the monitors by vendor.** Create a folder per vendor holding their disclosure page, advisory index, and trust centre, so one folder shows every signal you track about them. ### What component changes should trigger an alert, and what should stay quiet? Escalate version bumps on components you have exposure to, new components appearing, components disappearing, licence changes, and any change to the terms governing SBOM access. Stay quiet on regenerated timestamps, reordered lists, formatting rewrites, and copyright year updates. The difference between a useful feed and an ignored one is entirely in that second list. #### Changes worth waking someone for A version bump on a component with an active advisory is the highest-value signal, because it tells you the vendor has shipped a fix before their advisory page has caught up. A brand new component is next: it expands your exposure surface and sometimes reveals a supplier relationship you did not know about. A component disappearing usually means a re-architecture that changes your patching assumptions. Licence changes on an embedded component create redistribution problems that otherwise surface at contract renewal. #### Changes that should stay in the history but not the inbox Most diffs on a disclosure page are noise: a new build timestamp, entries re-sorted alphabetically, refreshed boilerplate, copyright years rolling over in January. All of it belongs in the archive and none of it belongs in a notification. Mark those regions as ignored after they trigger once, and the page settles into silence until the inventory genuinely moves. #### Connecting a component change to a real vulnerability A component list is only half the answer. The other half is knowing which components are being exploited, which is what the [CISA Known Exploited Vulnerabilities catalogue tells you](/blog/cisa-kev-catalog-cve-monitoring-security-teams). Track both and you get a crossover: a KEV addition names a component, and a search across your captured vendor disclosures tells you which purchased products list it. [Tracking package registry releases](/blog/pypi-npm-package-release-supply-chain-monitoring) covers the upstream side of the same supply chain. ### How does component disclosure monitoring fit the Cyber Resilience Act timeline? The EU Cyber Resilience Act obliges manufacturers of products with digital elements to document their components in a machine-readable software bill of materials covering at least the top-level dependencies. According to the European Commission, the regulation entered into force in December 2024, reporting obligations apply from 11 September 2026, and the main manufacturer obligations apply from 11 December 2027. That timeline means your suppliers' disclosure pages are being created, restructured, and moved right now. Pages appear, coverage widens, formats change from a PDF appendix to a downloadable CycloneDX or SPDX file. Watching those pages during the run-up is how you find out which of your vendors is preparing and which is going to be scrambling. The [Commission's Cyber Resilience Act pages](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act) are the authoritative source for the obligations and the dates. #### Evidence you can hand to an assessor Assurance reviews increasingly ask what you knew about a supplier's components and when. A monitoring archive answers directly: the disclosure document as published on a given date, the diff when it changed, the alert that went to the security channel. That beats an email thread asking a vendor for a document nobody kept a copy of. ### What goes wrong when you monitor vendor disclosure pages? The common problems are pages that move without a redirect, disclosure documents locked behind a login or a request form, PDF files whose text layer changes shape between releases, and lists so long that every regeneration produces a large diff. All four are workable once you know they are coming. #### Pages that move or version themselves A per-version disclosure page often has the version number in the URL, so a major release produces a new page rather than an updated one. Watch the parent index as well as the specific document, so a new version appearing in the index tells you to add a monitor. If a monitored URL starts returning an error page, treat that as a signal, not a broken monitor. #### Documents behind a login or a request form Some vendors put the SBOM behind an authenticated portal or a request workflow. You cannot monitor a document that only exists after a manual request, but you can monitor the page stating the policy, which is often where the meaningful change happens. Where the document lives behind a customer login, authenticated monitoring can watch the logged-in view. Read the vendor's sharing terms first, because many SBOM programmes restrict redistribution. #### PDF disclosure documents A large share of these documents are PDFs, sometimes thousands of pages of licence text with the component table buried inside. PDF extraction mode compares the text, which handles the common case of a vendor regenerating the file with an identical component list and a different internal identifier. #### Very long lists and diff fatigue A list with two thousand entries produces a big diff whenever the build tooling changes its sorting. This is where keyword rules matter most. Define the twenty component names that actually change your risk posture, let those drive escalation, and let everything else accumulate quietly in the history for the day you need to search it. ### Choosing your PageCrawl plan PageCrawl's **Free plan** lets you monitor **6 pages** with **220 checks per month**, which is enough to validate the approach on your most critical pages. Most teams graduate to a paid plan once they see the value. | Plan | Price | Pages | Checks / month | Frequency | |------|-------|-------|----------------|-----------| | Free | $0 | 6 | 220 | every 60 min | | Standard | $8/mo or $80/yr | 100 | 15,000 | every 15 min | | Enterprise | $30/mo or $300/yr | 500 | 100,000 | every 5 min | | Ultimate | $99/mo or $999/yr | 1,000 | 100,000 | every 2 min | Annual billing saves two months across every paid tier. Enterprise and Ultimate scale up to 100x if you need thousands of pages or multi-team access. At an engineering hourly rate, Standard at $80/year pays for itself the first time you catch a breaking API change, a deprecated endpoint, or a silent config change before it takes down production. 100 monitored pages is enough to cover the changelogs and docs of every third-party API your stack depends on. Enterprise at $300/year adds higher check frequency, 500 pages, and full API access. All plans include the **PageCrawl MCP Server**, which plugs directly into Claude, Cursor, and other MCP-compatible tools. Developers can ask "what changed in the Stripe API docs this month?" and get a summary pulled from your own monitoring history. AI assistants can create monitors through conversation on every plan, including Free, turning your tracked pages into a living knowledge base instead of a pile of alert emails. ### Getting Started Start with the five purchased products whose compromise would hurt most, and find the page where each vendor discloses its components. Add those five URLs as monitors in reader mode, set them to a daily check, and route the alerts to the channel your security team already watches. Once the first diffs arrive, spend ten minutes marking the generated timestamps and re-sorted sections as ignored, then add keyword rules for the component names on your exposure list. From that point the feed is quiet until something real moves. Then widen it. Add the SBOM policy pages and the vendor advisory indexes into the same per-vendor folders, and let the archive build. The next time an advisory drops on a Thursday afternoon, the question of what is inside the software you bought will already have a dated answer. Stop rediscovering your vendors' components during the incident. Start watching the pages that hold them. --- Need more? The complete PageCrawl.io help center, with every article, is available as a single document at https://pagecrawl.io/llms-full.txt. Read it for context on anything this page does not cover.