devguard

Vulnerability classes

Keep the catalog of weaknesses that classifies your risks, so the same weakness has the same name across the register.

A vulnerability class names a weakness that a threat can exploit. Examples: a flat network without segmentation, weak passwords, unpatched systems, backups stored without encryption.

A threat class says what can happen. A vulnerability class says why it could succeed. Each risk has one of each. So you can ask the register which of your weaknesses carry the most risk, not only which threats.

Build the catalog

  1. Open Risks → Vulnerability Classes and select Add vulnerability class.
  2. Give it a name and a description of the weakness and where it usually is. devguard creates the slug from the name.
  3. In the risk form, choose one vulnerability class under Impact for each risk.

The template picker also builds the catalog. When you create risks from templates, it links the vulnerability class that each template names. If you have no class of that name, it creates one, matched on the slug.

Name the weakness, not the fix. "Flat network without segmentation" stays true until the network is segmented. "Missing segmentation project" reads like a task and is soon out of date.

Reference

Fields

FieldHolds
NameThe weakness; required
SlugCreated from the name; the identifier in URLs and the API
DescriptionWhat the weakness is and where it is

Where a class is used

The class's detail page lists the risks classified under it, with Comments and History tabs. The register filters by vulnerability class. Archiving a class hides it from pickers. Deleting a class removes it from the risks that used it.

Import and export

The list's menu offers Import CSV, Download CSV template, and the exports. The template's columns are slug, name, and description. A blank slug is created from the name. Delimiters, encodings, and refused rows work as for risks.

vulnerability-classes.csv
name;description
Flat network without segmentation;One compromised host can reach every other
Weak password policy;Short or reused passwords without a second factor
Backups stored without encryption;A copied backup is readable by whoever holds it

Permissions and API

Owners, admins, and organization tokens create, edit, archive, and delete vulnerability classes. Members and auditors can only read.

MethodPathPurpose
GET, POST/vulnerability-classes/List and create
GET, PATCH, DELETE/vulnerability-classes/{id}/Read, update, delete
POST/vulnerability-classes/{id}/archive/Archive
POST/vulnerability-classes/{id}/restore/Restore

A risk names its class with vulnerabilityClassId on POST /risks/ or PATCH /risks/{id}/.

How is this guide?

On this page