Glossary
Each term is followed by where you meet it in the application and the page of the guide that covers it.
Vulnerabilities and signals
Section titled “Vulnerabilities and signals”Common Vulnerabilities and Exposures. The public identifier of a vulnerability, in the form CVE-2021-44228 (year, then number). A CVE describes a flaw, the affected products and versions, and the versions that fix it.
Where: the CVE database (Monitoring › CVEs), every alert, search (Ctrl K). See CVE database.
Common Vulnerability Scoring System. A severity score from 0 to 10, based on how the flaw is exploited (remotely or not, with or without privileges, with or without user action) and on its consequences. The application turns it into levels: Critical, High, Medium, Low, None.
Where: on every CVE (the CVSS score property and the collapsible CVSS details section), severity badges, the dashboard’s Open exposure widget, and prioritisation (“Alerts from CVSS 7”). See CVE database.
Exploit Prediction Scoring System, published by FIRST.org. The probability that a vulnerability will be exploited within 30 days, from 0 to 100%. Where CVSS says “how bad”, EPSS says “how likely”.
Where: the EPSS 94% badge in lists, the CVE record, the EPSS distribution in Statistics, workflow conditions, the Exploitation first prioritisation model.
Known exploitation
Section titled “Known exploitation”A vulnerability that is known to be already used by attackers. TechWatchAlert combines several sources for this: the KEV catalogue, the EUVD, CERT-FR and VulnCheck.
Where: the Exploited badge, the prioritisation models (“known exploitation first”), the matching workflow trigger. With the default model, an exploited vulnerability raises an alert even below the CVSS threshold.
Known Exploited Vulnerabilities, the catalogue kept by CISA (the US cybersecurity agency) of vulnerabilities exploited in the wild.
Where: known exploitation (the Exploited badge), the Added to KEV workflow trigger, the KEV filter in the CVE database, the “KEVs added per month” chart in Statistics.
European Union Vulnerability Database, the European vulnerability database run by ENISA. It also flags exploited vulnerabilities.
Where: the sources of known exploitation, the “View … on the EUVD website” link on a CVE record.
CERT-FR
Section titled “CERT-FR”The French government’s computer emergency response team, part of ANSSI (the French national cybersecurity agency). It publishes security advisories and alerts.
Where: the CERT-FR badge on a CVE cited by CERT-FR, the National sources in the NIS2 compliance area, the sources of known exploitation.
Ransomware
Section titled “Ransomware”Malicious software that encrypts data to demand a ransom. A vulnerability used by ransomware (according to the CISA or VulnCheck KEV catalogues) is flagged separately: fix it first.
Where: the ransomware badge on a CVE and the “why this alert” explanation.
Proof of Concept: public code showing how to exploit a vulnerability. Its publication makes an attack easier, and therefore more likely.
Four sources are tracked: GitHub repositories listed by nomi-sec/PoC-in-GitHub, Exploit-DB, Metasploit modules and Nuclei detection templates. They give the exploit maturity: Exploited (confirmed exploitation), Weaponized exploit (a Metasploit module or a Nuclei template allows the attack without writing code), Public proof of concept (GitHub, Exploit-DB) or none.
Where: the PoC 3 badge (or Weaponized for a weaponized exploit), the Exploitation section of a CVE record (View PoCs button), the PoC published workflow trigger and the Has PoC? condition.
Stakeholder-Specific Vulnerability Categorization, a CISA decision method: rather than a score, it qualifies exploitation, impact and whether the attack can be automated.
Where: the Exploitation section of a CVE record, when CISA has published one.
Common Weakness Enumeration. The catalogue of weakness types (SQL injection, buffer overflow…). A CVE is a specific flaw; its CWE says which family it belongs to.
Where: the Weaknesses property of a CVE record, the “Top 15 weaknesses (CWE)” in Statistics.
CVE Numbering Authority. The organisation (vendor, CERT, researcher) that assigned the CVE identifier and published the original record, often with its own CVSS score.
Where: the Assigned by line in the header of a CVE record or an alert record; CVSS details shows one tab per source when there are several scores.
NVD, GHSA, OSV
Section titled “NVD, GHSA, OSV”Public databases that complement CVEs: the NVD (the US database), GitHub security advisories (GHSA) and the OSV database for open-source ecosystems.
Where: the sources of a CVE record’s Fixed versions and References; a record “pre-published from external advisories (GHSA/OSV)” when the CVE is not yet in the official database.
Inventory
Section titled “Inventory”A project’s inventory: the vendors and products it uses, with their version when you know it. The stack belongs to the project and is shared by its whole team; imports, connectors and URL auto-follow feed it too. It decides which alerts are raised: a CVE that affects nothing in the stack raises no alert.
Where: Monitoring › Stack, the start-up wizard. See Stack.
Common Platform Enumeration. The standard identifier of a product (vendor:product:version), used by CVEs to say what they affect. Each entry in the stack is matched to the CPE catalogue: that match is what lets TechWatchAlert recognise your products in CVEs. An unmatched entry (shown in orange) raises no alerts.
Where: assisted stack entry (“Products” and “Vendors” suggestions), the “With CPE” filter in the CVE database, the explanation of a discarded alert (“the CVE’s CPE references point to another vendor”).
Software Bill of Materials: the list of a piece of software’s components, produced by build tools. TechWatchAlert reads the CycloneDX format (JSON or XML).
Where: Import a file on the Stack page and Imports, connectors and scans; Try without an account.
Manifest
Section titled “Manifest”A software project’s dependency file (package.json, requirements.txt, go.mod…). TechWatchAlert extracts the components from it.
Where: Stack imports, the trial without an account.
End of life (EOL)
Section titled “End of life (EOL)”The date from which the vendor publishes no more fixes for a version. The end of active support, which often comes first, is the end of ordinary updates and fixes. A component that is out of support may keep known vulnerabilities that can never be fixed.
Where: Monitoring › End of Life, “end of life in N days” notifications, the deadlines widget, the default end-of-life workflows. See End of life.
Monitored URL
Section titled “Monitored URL”A website that TechWatchAlert visits regularly to detect the technologies it exposes (and fill the stack) and to track the expiry of its HTTPS certificate.
Where: Monitoring › URLs. See Monitored URLs.
Organising the work
Section titled “Organising the work”Organisation
Section titled “Organisation”The workspace of a company or team: members, roles, subscription, prioritisation policy, SSO, API keys. See Organisations.
Project
Section titled “Project”A monitored scope within an organisation (an application, a website, a fleet). All the monitoring work is attached to it and shared by its team: the stack, the alerts and their cases, workflows and webhooks, watch reports and the project settings (prioritisation policy, end-of-life lead times, webhook sending). The active project is chosen at the top of the sidebar. See Projects.
Prioritisation policy
Section titled “Prioritisation policy”The organisation’s rules that set the order of alerts and what raises an alert. Four models are offered (Combined risk, Exploitation first, CVSS + known exploitation, CVSS only), or custom settings.
Where: the start-up wizard, the organisation settings, the reminder at the top of the Stack page. See First steps and Organisations.
The signal that a CVE affects a project’s stack and passes the prioritisation policy. There is one alert per project and per CVE, shared by the team: a new member sees the existing alerts. Only the read or unread state is personal. Only CVEs published since the project was created become alerts: an older vulnerability can be browsed in the CVE database, without an alert. When a vulnerability published since that date affects a component just added, the alert is created straight away (“already published vulnerabilities… are in its alerts”).
Where: Overview › Alerts and its badge. See Alerts.
The handling of a CVE within a project, which the application also calls a follow-up (“Create case”, “suivi” in French). Its statuses: To do, Analyzing, Remediating, Risk accepted, Resolved, Not applicable. There is one case per project and per CVE, shared by the team: status, internal notes, comment thread, history (who made each change), assignee, tags and ticket are the same for everyone; only reading (alert and comments read) is personal. Each action on the case depends on a specific right: without write rights, the record is shown read-only.
Where: an alert’s record (tracking bar, Case column), the Project cases widget and the remediation metrics of the dashboard. See Handling an alert.
Assignee (assignment)
Section titled “Assignee (assignment)”The people who own a case for the team: one or more per case, chosen among the project members who can see cases. Each is notified in their bell and by email (Assignments preference); their initials show in the alert list, whose My assignments filter finds your cases. Metrics in the Assigned to me scope only count cases whose CVE is assigned to you. A member who leaves the project loses their assignments.
Where: the Assignee line of the Case section and the Assign button of the tracking bar of an alert record, the action bar and the initials column of the alert list, the cog of the remediation metrics. See Assigning the case.
A coloured label defined by the organisation (“Production”, “Exposé Internet”…), placed on a CVE’s case in a project, on a stack item or on a project. A case’s tags are shared by the team; they are used to filter alerts, in reports and in workflows (the “Add a tag” action).
Where: the Tags line of the Case section of an alert record, the Tags filter of the alert list, the organisation’s Tags page. See Organisations.
Triage
Section titled “Triage”The first sort of alerts: deciding which to analyse, fix, accept or dismiss.
Where: the Project cases widget (“To do”, “Analyzing”, “Remediating”, “Nothing to triage”). See Handling an alert.
Not applicable
Section titled “Not applicable”The case status for a CVE that does not concern the project: false positive, component not exposed, feature disabled. This is how a CVE is dismissed, with an optional reason posted to the comments; the case moves to History for the whole team and can be reopened. For a whole component, adjust the stack (alert threshold or removal).
Where: the Not applicable button in the alert record’s tracking bar. See Handling an alert.
Accepted risk
Section titled “Accepted risk”The formal decision not to fix a vulnerability (or not yet), with an analysis, compensating measures, approval and a review date. More binding than Not applicable: the CVE does affect you, but you are not fixing it.
Where: the Risk accepted case status and the Accepted risks register in the NIS2 area. See Registers.
Workflow
Section titled “Workflow”A “trigger → conditions → actions” automation (create a case, notify, send an email, call a webhook…). Every notification goes through a workflow; each project gets five by default.
Where: Workspace › Workflows. See Workflows.
Webhook
Section titled “Webhook”A web address (yours, or that of a tool such as Slack or Teams) that TechWatchAlert calls to pass on an event, in JSON or in the format the tool expects. Every call is signed (X-TWA-Timestamp and X-TWA-Signature headers), so that the receiver can check it really comes from TechWatchAlert.
Where: project settings (Project webhooks, and the Send webhooks switch of the Team notifications card), the “Call webhooks” workflow action. See Notifications and channels.
Accounts and access
Section titled “Accounts and access”Role, group
Section titled “Role, group”A role sets what a member can do in an organisation or project; a group grants roles to several members at once. See Team, roles and groups.
Two-factor authentication (2FA)
Section titled “Two-factor authentication (2FA)”A 6-digit code, produced by an authenticator app, asked for after the password. Single-use recovery codes are there in case the app is lost.
Where: Settings › Security, the Two-step verification screen. See Account and sign-in.
Single sign-on: sign-in goes through the company’s identity provider (OIDC). An organisation can require it for its domains.
Where: the Sign in with your organization’s SSO button on the sign-in screen, the organisation settings. See Organisations.
API key
Section titled “API key”A secret that lets a program query TechWatchAlert without a password.
Where: organisation settings (Organization API keys); how to use it is covered in the API part of the documentation.
The organisation’s subscription: Free, Team, Pro, Business. It sets the modules included and the limits (projects, members, stack entries, URLs). A module that is not included is marked with a padlock.
Where: the subscription item in the user menu, the padlocks in the sidebar. See Plan and billing.
Compliance and providers
Section titled “Compliance and providers”The European directive (EU) 2022/2555 on the security of network and information systems. The NIS2 compliance area supports the part that concerns vulnerabilities, inventory, suppliers and incidents, and produces the evidence to present; it does not make you “compliant” on its own.
Where: Compliance › NIS2 compliance, switched on project by project. See NIS2 compliance.
Managed Service Provider: a company that runs the IT of several clients. With the Partner plan, it gets the Partner space, which brings together all its clients.
Where: Context › Partner space selector, at the top of the sidebar. See Partner space.
White labelling
Section titled “White labelling”The provider’s logo instead of TechWatchAlert’s: on its clients’ PDF reports (monitoring, NIS2, registers, incident records) and in their sidebar. Depending on the provider’s plan, the words “via TechWatchAlert” remain.
Where: Partner space › Branding for the partner’s logo; a client organisation’s settings for its own logo. See Team, billing and branding.
The AI assistant’s name. You talk to it privately through the Vigie entry in the Team chat channel switcher (the team chat rail on the right edge of the screen, Ctrl J). It does not take part in team chat (the organisation channel, direct messages).