Populating your stack

A project’s stack is the list of vendors and products TechWatchAlert monitors for you. It decides which CVEs become alerts: everything starts here.

Note

The public v1 API is read-only (GET /v1/organizations/{org_id}/projects/{id}/stack). Filling the stack happens in the app, through the four paths described here. (A scan report uploaded by CI — POST …/scans — does not fill the stack: it checks it against what is actually installed.)

Before you even have an account

The Check your stack page takes a manifest, an SBOM or a “name version” list and shows within seconds the known vulnerabilities in those versions, exploited ones first. Nothing is kept; if you then create an account, the recognised components prefill your first project’s stack, and already-published vulnerabilities land in your alerts straight away.

Which path should you use?

You have…	Path	Alert precision
A production URL	Detect from a URL	★★★ vendor and version detected
A code repository	Import a manifest	★★★ exact versions from lockfiles
A CycloneDX SBOM	Import an SBOM	★★★ normalized identifiers
None of the above	Search or a preset	★★ product name only

The first three fill in a normalized vendor (from a CPE) alongside the product name. That is what rules out same-name products from other vendors: two products called nginx from two different vendors do not trigger the same alerts.

1. Search

The Add to stack field searches vendors and products at the same time — no need to pick a type upfront, it is shown on each result.

• Results appear from the first character you type — not before: a ranking shown on an empty field has nothing to do with what you are looking for.
• One row per product, with the vendors that publish it underneath. Those labels come from the CVEs, where the same vendor is spelled ten different ways (redhat, Red Hat, Inc., redhat.com): they help you recognize the product, but are not used as an alerting criterion.
• The known CVE count hints at exposure.
• Keyboard: ↑ ↓ to navigate, Enter to add, , to commit and keep going, Escape to close, Backspace on an empty field to remove the last entry.
• The ⓘ button next to the field recaps all of this on demand.

Adding a name that is not in the catalog

The last row of the list always offers “Add “your input””. A product no CVE mentions yet is still perfectly monitorable — it is in fact the only way to be alerted on its first CVE. Those items carry a 0 CVE badge until a CVE cites them; the badge clears itself the day one does.

2. Paste a list

Paste several names separated by commas, semicolons, tabs or newlines — typing a comma also commits the current entry:

nginx, openssl, postgresql, redis

Each name becomes an entry. They are then matched against the catalog automatically to recover the vendor whenever the name matches exactly.

3. Import a manifest or an SBOM

Import a file accepts a CycloneDX SBOM (JSON or XML) or a dependency manifest:

Ecosystem	Recognized files
npm	package.json, package-lock.json, npm-shrinkwrap.json
PyPI	requirements*.txt, Pipfile.lock, poetry.lock
Go	go.mod
Composer	composer.json, composer.lock
Maven	pom.xml
RubyGems	Gemfile.lock
Cargo	Cargo.lock

Limits: 5 MB, 5,000 components.

Versions: only exact ones are kept

A range constraint (^4.17.21, >=2.0, ~1.2) does not say what is actually installed. Recording its lower bound would hide CVEs that do apply — the worst of both worlds. Such components are therefore imported without a version, meaning they are watched across all versions.

In practice: a lockfile (package-lock.json, poetry.lock, Gemfile.lock, Cargo.lock, composer.lock) yields exact versions and therefore precise alerts. A top-level manifest (package.json, composer.json) mostly yields ranges. Prefer the lockfile when you have one.

Review screen

Nothing is saved before you confirm. Each component shows whether a CVE already cites it and whether it is already in the stack. Components with no known CVE are unchecked by default but selectable — your call on whether they are worth monitoring.

4. Detect from a URL

Detect from a URL reads a page’s headers and HTML to recognize the technologies it serves. It is the fastest path and often the most precise: the signatures return full CPEs, so vendor and version come pre-filled.

Nothing is saved — neither the URL nor the technologies — until you confirm the review screen. For continuous tracking of the same URL, use Monitored URLs instead, which rescans periodically and can feed the stack automatically.

Caution

Scanning is capped at 10 URLs per 5-minute window per account. Private addresses (local network, loopback) are rejected.

Presets

On an empty stack, six presets lay down an editable starting point in one click: PHP web / LAMP, Node & front-end, Python, Java / JVM, Containers & K8s, Workstation. They do not replace a real inventory, but they beat a blank page.

Tuning the noise

Two per-item settings, editable at any time from the table:

• Minimum severity — the threshold below which no alert is raised. All surfaces everything, Critical only the worst.
• Version — empty means all versions. Once set, it rules out CVEs whose affected ranges do not cover it, which cuts noise sharply.

See GET /v1/…/stack to read the stack back from the API.