Stack

The stack is the list of vendors and products TechWatchAlert monitors for a project. It decides which CVEs become alerts: a CVE that touches nothing in the stack produces nothing. The more accurate the stack (right names, exact versions), the more accurate the alerts.

The screen is under Monitoring › Stack. It shows the stack of the active project, the one chosen under Active project at the top of the menu; the project name is shown next to the title. With no active project, the page only says “Select a project to see its stack”.

1. Detect from a URL, Import a file and Add to stack: the three ways to fill the stack (see Adding an item by hand and Imports, connectors and scans).
2. Policy banner: the project’s alert rule in one sentence, and a warning when items depart from it.
3. Type: All, Vendors or Products, with their counts.
4. Alert threshold filter.
5. Search within the stack, and the number of results.
6. Tag filter (shown when the organisation has tags).
7. Column headers: clicking Name, Type or Alert threshold sorts the list.
8. Badges on an item: here 0 CVE and GLPI.

One stack per project, shared by the team

The stack belongs to the project: all its members see the same items, and those with the right keep it up to date together. The alerts it produces are the project’s, visible to the whole team. File imports (SBOMs, manifests), URL detection and auto-follow, and inventory connectors (GLPI, Intune) all feed this same stack, whoever runs them. Removing a member from the project removes nothing from the stack.

What goes into the stack

A stack item is one of two types:

Product

A specific piece of software: nginx, openssl, postgresql, wordpress… This is the usual case. A product can carry a version: only CVEs affecting that version raise alerts.

Vendor

A whole vendor: microsoft, apache… Any CVE in one of that vendor’s products may alert. A vendor never carries a version (the column shows “—”). Keep it for vendors whose products you use widely.

Names are those used in CVEs (the NVD CPE vocabulary): http_server for Apache HTTP Server, node.js, linux_kernel… The add search suggests them, so you don’t need to know them by heart.

For a CVE to become an alert, the engine checks, in order:

1. the name: the item’s product (or vendor) is among the CVE’s, ignoring case;
2. the vendor, when the item knows one (import, URL detection, connector): a CVE for a same-named product from another vendor is set aside;
3. the version, when the item has one: the CVE is kept only if one of its affected version ranges covers yours (a CVE with no range at all is kept to be safe);
4. the item’s alert threshold (see Alert threshold).

When several items match the same CVE (say the vendor microsoft and a Microsoft product), only one alert is created for the project, attached to the broadest item (the vendor).

Only new vulnerabilities become alerts

An organisation is only alerted about CVEs published since it was created (to the day). Declaring your stack right after signing up therefore raises no alert for old vulnerabilities: they can still be browsed in the CVE database.

When you add an item to an older project, TechWatchAlert catches up on the CVEs published since the project was created that affect it: those from the last 12 months, plus those in the known-exploited catalogue (KEV), at most 150 per addition, exploited ones first. They appear straight away in Alerts, marked as published before the item was added, and a message says so (“3 already published vulnerabilities affect the project’s stack: they are in its alerts.”). This catch-up sends no email and no notification.

The item list

Each row describes one stack item. By default the list is sorted by name, A to Z.

Column	What it shows
Checkbox	Selection for bulk actions (only if you may remove items). The header box Select all ticks the visible items.
Name	Logo (or initial), item name and badges. The name links to the CVE database filtered on that product or vendor.
Type	Product or Vendor.
Version	The monitored version, or All versions. Click it to change it.
Alert threshold	The project policy or the item’s own threshold.
Criticality	Only when NIS2 is turned on for the project (see Criticality).
Tags	The item’s tags, and + to add one.
×	Removes the item from the stack.

The stack shows neither CPEs nor linked alerts: the CPE and vendor brought by an import or URL detection are kept and used for matching, without being displayed; alerts are read in Alerts, where each one says which item raised it.

Badges

• 0 CVE: no CVE mentions this name yet. That is not an error: monitoring stays on and you will be alerted on the first one. The badge is recalculated on every display and disappears the day a CVE names the product. If it stays on a well-known piece of software, check the spelling (the expected name often differs from the brand name).
• GLPI or Intune: the item is kept up to date by an inventory connector. Its version follows the inventory, and it disappears if the software is uninstalled.

Filtering, searching, sorting

• All / Vendors / Products limits the list to one type.
• The All thresholds list offers Project policy (items inheriting the policy), Refined thresholds (items with their own threshold), then a specific threshold (Critical, High, Medium, Low, All).
• Search a vendor or product in this stack… looks for the typed text in item names (case ignored). The cross clears the field.
• Tags: a click turns a tag on or off; with several tags on, the list shows items carrying at least one of them. Reset turns them all off.

Filters combine. When nothing matches, the page shows “No results” and a Clear filters button.

Sort by clicking Name, Type or Alert threshold; a second click reverses the order. Sorting by threshold orders items by their effective threshold (their own, otherwise the policy’s), from broadest to strictest; at equal threshold, an inheriting item comes before a refining one.

Adding an item by hand

Add to stack opens a search window. It can add several items at once: you first put them in a To add queue, tune them, then confirm.

1. Click Add to stack.

2. If needed, choose the search scope: Vendors, Both (default) or Products. Narrowing the scope helps when the result list is too long.

3. Type a name in the field (at least one character). Suggestions appear, grouped into products and vendors; each result shows the vendors that publish it and how many CVEs are already on record (“12 CVEs”, or “0 CVE”). A result already in the stack or already queued is greyed out and marked already added.

   

4. Click a result, or pick it with the arrow keys and Enter. It joins the To add queue and the field clears for the next one.

5. If the name you are looking for appears in no CVE, the last row offers Add “…” (free text): the only way to monitor a product before its very first CVE.

6. Tune each queued item: its alert threshold (gauge) and, for a product, its version (see below). The cross removes an item from the queue.

   

7. If needed, choose the Threshold for added items: it applies to the whole queue at once (the project policy by default).

8. Click Add N item(s).

A few shortcuts, recalled by the i to the right of the field (“How it works”):

• Paste a list: “nginx, openssl, redis” (separated by commas, semicolons, new lines or tabs) creates three entries at once. Typing a comma or semicolon also commits the current entry. Pasted names are then matched to the catalogue in the background (“Resolving…”) to fetch their vendor; those matching nothing are flagged 0 CVE.
• Keyboard: ↑ ↓ to browse, Home and End for the first or last result, Enter to add, Escape to close the list, Backspace on an empty field to remove the last queued entry.

After sending:

• items already present are refused one by one (““nginx” is already in the stack (case does not matter).“); the others are added;
• a message confirms how many items were added, and another announces the vulnerabilities caught up, if any (published since the project was created);
• if sending fails (rights, plan quota, network), a message explains why and the queue is kept so you can retry.

An item with no known CVE is added anyway; the window says so under the queue (“1 item(s) with no known CVE so far. They are added anyway”).

Alerts compare names exactly: “httpd” or “http” in the stack never trigger anything, while Apache’s CVEs use http_server. So when a name appears in no CVE, the queue suggests close names that do, under the item: “No CVE uses this name. Did you mean: http_server (3 CVEs)”. One click replaces the item. Suggestions come from common short names (httpd, sshd, postgres…), close spelling (one missing letter) and CVE names that contain what you typed.

The end-of-life tracking prompt

When you add, by hand, products that are in the end-of-life catalogue (PHP, PostgreSQL, HAProxy…), a Track end of life? window opens right after the addition.

• Follow new versions subscribes the project to the whole product: an alert whenever a new version ships.
• The Versions list shows each version with its Support ends and End of life dates. Tick the ones you run to be warned before their deadlines. Versions whose end of life is near (under 180 days) and that you do not follow yet are ticked in advance. A version already past is marked PAST but can still be ticked: its end of support may still be ahead.
• What you already follow is ticked and greyed out (Already followed).
• Follow (N) saves the subscriptions; Later (or Escape) closes without saving anything.

This prompt does not appear for file imports or URL detection. Subscriptions are explained in End of life.

Why the version matters

A product with no version monitors every version: any CVE for the product may alert, including ones fixed long ago on your side. With the exact version, only CVEs that really affect it alert. It is the setting that removes the most noise.

To choose or change a version, click the pill in the Version column (or in the add queue):

• The list shows the versions known from CVEs for this product, newest first (40 at most). Type the start of a number to filter: the filter queries the server and also finds versions older than those displayed.
• All goes back to monitoring every version.
• If your version is not listed, type it: it is offered with the typed tag; click it (or press Enter).
• The bottom line recalls the effect: “Only CVEs affecting version 1.24.0 will raise an alert.”

Keep the version up to date

A stated but outdated version misses the CVEs of the version actually installed, and vice versa. After an upgrade, change the version in the stack. Inventory connectors and manifest imports provide exact versions; vulnerability scans show what actually runs.

The version also drives end-of-life tracking: it links a product to its cycle (“3.0.13” belongs to cycle “3.0”). A product with no version cannot be assessed.

Alert threshold: the project policy, refined per item

What raises an alert is decided first by the project’s prioritisation policy (project settings, Alerts page; see Projects). The banner at the top of the page sums it up, for example: “Alerts follow the project policy (Combined risk): from CVSS 7, or below if the CVE is exploited.” The Edit the policy link opens that setting; without the right to configure the project, it reads View the policy and opens it read-only.

Each item can refine the threshold in the Alert threshold column:

• the Policy pill: the item inherits the project policy (recommended). The cubes then show the policy’s equivalent, dimmed, and the text on the right says “CVSS ≥ 7”;
• the five cubes, left to right: All (any CVE), Low (CVSS ≥ 0.1), Medium (CVSS ≥ 4), High (CVSS ≥ 7), Critical (CVSS ≥ 9). Clicking a cube sets the item’s threshold; colour runs from the threshold to the right: what is coloured will raise an alert. With the keyboard, the arrow keys move the threshold.

The item’s threshold only replaces the policy’s minimum CVSS; the rest of the policy still applies (for instance alerting below the threshold for an exploited CVE, if the policy does so).

An item that departs from the policy shows an amber triangle, whose tooltip quantifies the gap; the same sentence appears for a few seconds under the gauge when you choose:

• stricter: “some CVEs of this item that would alert for the project will not”;
• broader: “expect more alerts”;
• same but pinned: the item will no longer follow policy changes.

Nothing is blocked. While at least one item refines its threshold, the banner says so (“1 item departs from the project policy.”) with:

• Show them: applies the Refined thresholds filter;
• Keep these refinements (or the cross): dismisses this message for every user of the project, after confirmation. The triangles stay on the rows;
• Edit the policy: to change the rule for every item rather than refining one by one.

To bring an item back to the policy, click its Policy pill.

Criticality (NIS2 projects)

When NIS2 is turned on for the project and the due-dates module is part of the plan, a Criticality column appears. It states what each item means for the business; it scales the remediation deadlines of its vulnerabilities (see NIS2 registers).

By default an item inherits the project’s criticality (“Project: Important”). The list lets you choose Vital, Important, Standard or Low for the item, or go back to the project’s criticality. Every change is logged.

On these projects a banner appears at the top of the page: the inventory review, only when it is near (7 days before it is due), due or overdue (due date, History, Record the review; the rest of the time the history is in the Inventory reviews tab of the compliance space; see NIS2 registers). Vulnerability scans are managed in the project settings, Scans tab (see Imports, connectors and scans).

Inventory review

Where inventory review runs (NIS2 projects), it happens on the Stack page, where the inventory lives. Each project’s inventory must be reviewed and the review recorded at a fixed interval; the history keeps the evidence.

• When a review is due, overdue or expected within 7 days, a banner says so above the list: “Inventory review due (last on 10 Sep)”, with History and Record the review.
• The rest of the time, a discreet line recalls the last review and the next one, with the History link.
• The address /stack#revue (notice links and the former Inventory reviews page) brings you to the banner and opens the history; ?projet= picks the project.

The rules:

• next review = the day of the last recorded review (or else of the project’s creation) + the interval (90 days by default, 7 to 365, set in the remediation policy);
• Due on the day itself, Overdue from the next day;
• only a recorded review resets the clock. An SBOM import is logged as evidence that the inventory is alive, but nobody attests having removed what no longer exists.

The History panel gives the project’s criticality, its dates, the last SBOM import, then the history: each recorded review and each import, with what changed since the previous one (items added, removed, versions changed) and the comment. In the footer: Record the review.

1. Go through the project’s stack.
2. Click Record the review.
3. Tick the four checks: obsolete items removed, versions up to date, new components added, criticality checked. Three out of four attest nothing: the button stays disabled.
4. Add a comment if needed (scope, sources, gaps), then Record the review.

The record is dated, signed with your name and kept. Recording a review requires the “Record an inventory review” project permission (analyst and above by default).

Reminders: when the review becomes due, the project’s administrators and owner and the security lead are notified, once per due date (NIS2 · Inventory reviews workflow).

Tags

The organisation’s tags (created in the organisation settings, Tags page) classify items: internet-facing, health data, production…

• The + in the Tags column opens the tag list; a click adds or removes a tag (tick = set).
• The cross on a pill removes the tag.
• With no tags in the organisation, the list says so (“No tags — create some in Organization settings → Tags.”).

Changing and removing items

• Version and threshold are changed right in the row; the change is saved immediately.
• The × at the end of a row removes the item, without confirmation. Alerts already created for the item stay in Alerts.

Bulk actions

Tick items (or Select all, which ticks the items visible with the current filters): a bar appears above the list.

• Alert threshold… applies a threshold to the selected items, or Back to the project policy; a message sums up the resulting gap.
• Criticality… (NIS2 projects) applies a criticality, or the project’s.
• Add tag… sets a tag on the whole selection (existing tags are kept).
• Remove removes every selected item, without confirmation.
• Deselect clears the selection.

Alert threshold… and Add tag… are only offered with the right to edit the stack; Criticality… follows the right to set criticality; Remove follows the right to remove from the stack.

Empty stack and presets

When the project’s stack is empty, the page offers to Start from a preset: six presets that each add five or six common products, to adjust afterwards.

Preset	Products added
PHP web / LAMP	http_server, php, mysql, openssl, wordpress, linux_kernel
Node & front-end	node.js, next.js, express, nginx, openssl, postgresql
Python	django, flask, requests, urllib3, postgresql, redis
Java / JVM	tomcat, spring_framework, log4j, openjdk, jenkins
Containers & K8s	kubernetes, docker, containerd, traefik, grafana, prometheus
Workstation	windows_11, office, edge, acrobat_reader, firefox, 7-zip

The Add to stack, Detect from a URL and Import a file buttons remain available under the presets. Presets add products without versions: remember to set versions afterwards.

On a phone

The list becomes a series of cards (name, type, version, large threshold gauge, criticality, tags). Adding goes through the floating + button; the … button in the header groups URL detection, file import and Select mode; filters live in a sheet opened from the settings icon to the right of the search.

Who can do what

Rights follow each person’s role in the project (see Team, roles and groups) and can be fine-tuned by administrators.

Action	User	Analyst	Admin	Owner
View the stack	✓	✓	✓	✓
Add (by hand, preset, URL)		✓	✓	✓
Import a file (SBOM, manifest)		✓	✓	✓
Change version and threshold, manage tags		✓	✓	✓
Remove items, bulk actions		✓	✓	✓
Change criticality (NIS2 projects)		✓	✓	✓
Dismiss the refined-threshold warning		✓	✓	✓

Each action follows a specific right, the same in the interface and on the server:

• Add (“Add to stack” right, the matrix’s Create column): without it, the header shows “You can view this stack, but you do not have permission to add items on this project.”;
• Import a file (“Import (SBOM / batch)” right): without it, the Import a file button does not appear;
• Change an item’s version, threshold and tags: “Edit item” or “Add to stack” right; without either, these values are shown read-only;
• Remove (“Remove from stack” right): without it, Read-only appears next to the result count and the remove buttons disappear.

What depends on your plan

• The Stack page itself must be included in the organisation’s plan; if it is not, its menu entry is locked and opens the plan picker.
• The number of stack items is capped by the plan, for the whole organisation (the stacks of all its projects together). With the instance’s default settings: 10 items on Free, 200 on Team, unlimited on Pro and Business. The Plan and billing page shows usage.
• An addition that would exceed the cap is refused as a whole; a message says so and the plan picker opens.

FAQ

Does a colleague see the items I add? Yes: the stack is the project’s (see the note at the top of the page). An item added by one member is monitored for the whole team, and the alerts it raises appear in every member’s list.

A member leaves the project: do their items disappear? No. Items belong to the project, not to the person who added them: they stay in the stack, as do the connectors and followed URLs.

I added a product, but it shows “0 CVE”. No CVE names it yet. If the product is well known, search for it again in the add window: the expected name (the one used in CVEs) often differs from the brand name (http_server for Apache).

Can I monitor two versions of the same product? Not from the add window, which refuses a name already present whatever its version. Inventory connectors and a URL’s auto-follow, however, can add one row per product-version pair.

Does removing an item delete its alerts? No. Alerts stay; simply, no new alert will come from that item.

Imports, connectors and scansSBOMs, manifests, URL detection, GLPI, Intune, Trivy and Grype scans.

End of lifeTrack end-of-support dates for stack products.

AlertsThe CVEs affecting the stack.

Populating your stack (API)Ways to fill the stack and how precise each is.