Vulnerability Custom Fields

Custom fields allow you to attach organization-specific metadata to vulnerabilities. Use them to track risk dimensions, compliance mappings, or internal classification data that is not captured by standard vulnerability attributes.

Custom fields are available on paid tiers. Free-tier organizations do not have access to this feature.

---

Creating Custom Fields

Step-by-Step

1. Navigate to Settings > Organization > Custom Fields.

2. Click Add Fields.

3. Fill in the following:

Field	Description	Required
Display Name	Human-readable name shown in the UI	Yes
Internal Name	Machine-readable identifier used in policies and API calls (unique per organization)	Yes
Field Type	TEXT or RANGE	Yes
Min Value	Minimum allowed value (RANGE type only, max 100)	Conditional
Max Value	Maximum allowed value (RANGE type only, max 100)	Conditional

1. Click Save.

The field type cannot be changed after creation. To change the type, delete the field and create a new one.

Limits

• Maximum of 2 custom fields per organization (one TEXT, one RANGE).

---

Field Types Supported

Type	Description	Validation	Example Use
TEXT	Freeform text value	No constraints	Risk region, business unit, compliance tag
RANGE	Numeric value within a defined range	Must be between min_value and max_value; max value cannot exceed 100	Risk score, impact rating, exploitability index

RANGE Field Constraints

• min_value must be less than max_value.

• min_value and max_value cannot be equal.

• Maximum value is capped at 100.

---

Usage in Dashboards

Custom field values are displayed on vulnerability detail views. Once a custom field is defined, it appears as an additional column or attribute when viewing vulnerability data for any SBOM in the organization.

---

Usage in Ticket Sync

Custom field values can flow into Jira tickets when the Jira integration is configured. If a custom field maps to a Jira custom field, its value is included in ticket creation and synchronization.

---

Usage in Policies

Custom fields can be used as policy rule subjects, enabling policy-based automation and enforcement.

Policy Rule Subjects

Subject Pattern	Field Type	Operators
VULN_CUSTOM_FIELD_{INTERNAL_NAME}	TEXT	IS, IS_NOT, EXISTS, NOT_EXISTS
VULN_CUSTOM_FIELD_{INTERNAL_NAME}	RANGE	LESS_THAN, MORE_THAN, RANGE
VULN_CUSTOM_FIELD_{INTERNAL_NAME}_AGE	TEXT (age-tracked)	LESS_THAN, MORE_THAN, RANGE

Example policy rule:

Fail if VULN_CUSTOM_FIELD_risk_score is MORE_THAN 80.

This creates a policy that flags vulnerabilities with a custom risk score above 80.

Age tracking (the _AGE suffix) is currently supported only for the risk_region internal name. This creates a virtual field that tracks how long a vulnerability has had a specific value.

---

Compliance Mapping

Custom fields can be used to map vulnerabilities to internal compliance categories:

• Risk classification: Use a TEXT field (e.g., risk_region) to tag vulnerabilities by geographic or regulatory scope.

• Impact scoring: Use a RANGE field (e.g., impact_rating) to assign a numeric impact score aligned with your compliance framework.

• Audit evidence: Custom field values are included in exports and can serve as evidence for compliance audits.

---

Best Practices for Standardization

• Use consistent internal names: Choose descriptive, lowercase, underscore-separated names (e.g., risk_region, impact_score). These names are used in policy rules and cannot be changed after creation.

• Document your fields: Maintain internal documentation of what each custom field represents, who is responsible for populating it, and how it maps to compliance or risk frameworks.

• Populate fields consistently: Incomplete data reduces the value of custom fields in dashboards and policies. Establish a process for populating fields during vulnerability triage.

• Use RANGE fields for quantitative risk: Numeric ranges integrate cleanly with policy rules (threshold-based enforcement) and provide sortable/filterable data in dashboards.

• Plan before creating: With a limit of 2 custom fields, choose carefully. Prioritize fields that support your most critical compliance or risk management workflows.

---

Common Misconfigurations

Issue	Symptom	Fix
Internal name contains spaces or special characters	Policy rule references fail	Use lowercase letters, numbers, and underscores only
Min and max values are equal (RANGE)	Validation error on save	Set distinct min and max values
Field type set incorrectly	Cannot use numeric operators on TEXT field	Delete and recreate the field with the correct type
Both fields used, need a third	"Add Fields" button disabled	Evaluate whether an existing field can be repurposed
Field deleted while referenced in policies	Policy rules referencing the field may not evaluate correctly	Update or remove policy rules that reference the deleted field before deleting it