Vulnerabilities

Vulnerabilities are the core findings in your security assessment. Hawkra provides a comprehensive system for documenting, tracking, and managing vulnerabilities across your workspace -- from initial discovery through remediation. Vulnerabilities can be created manually, imported from scan tools, or generated from your Findings Library templates.

How It Works

Each vulnerability in Hawkra represents a discrete security finding within a workspace. Vulnerabilities are independent entities that can be linked to one or more assets, enabling you to track which hosts are affected and monitor remediation progress per asset. This many-to-many relationship between vulnerabilities and assets reflects real-world scenarios where a single weakness (e.g., an outdated TLS configuration) may affect multiple systems.

Creating Vulnerabilities

Manual Creation

To create a vulnerability manually, navigate to the Vulnerabilities section of your workspace and fill in the following fields:

Field	Required	Description
Title	Yes	A descriptive name for the vulnerability (1-255 characters)
Severity	Yes	The severity level (see Severity Levels below)
Description	No	Detailed description of the vulnerability (up to 10,000 characters)
CVSS Score	No	The CVSS base score, validated between 0.0 and 10.0
CVE	No	The CVE identifier (e.g., CVE-2024-1234), up to 50 characters
CWE	No	The CWE identifier (e.g., CWE-79), up to 50 characters
Impact	No	Description of the business or technical impact (up to 10,000 characters)
Recommended Fixes	No	Remediation guidance and recommended fixes (up to 10,000 characters)
Reference	No	A URL to external documentation or advisories (up to 2,000 characters, validated as a proper URL)

tip

Be thorough with the description, impact, and recommended fixes fields. These are included in generated reports and provide the context that stakeholders need to prioritize remediation.

Creating from Findings Library

If you have a Findings Library with pre-defined vulnerability templates, you can create a vulnerability directly from a template. This pre-fills all fields from the template, saving time for commonly encountered findings.

When creating from a template, you can optionally specify asset links at the same time -- selecting which assets (and optionally which specific ports on those assets) are affected. This creates the vulnerability and all its asset associations in a single step.

To learn more about the Findings Library, see the Findings Library documentation.

Saving to Findings Library

You can also work in the other direction: after documenting a vulnerability during an assessment, save it back to your Findings Library as a reusable template. This is particularly useful for building up your personal library of common findings over time.

Severity Levels

Every vulnerability must be assigned a severity level. These levels follow industry-standard classifications and are used for prioritization, filtering, and reporting.

Severity	Color	Typical CVSS Range	Description
Critical	Red	9.0 - 10.0	Immediate exploitation risk. Can lead to full system compromise with minimal effort
High	Orange	7.0 - 8.9	Significant risk that should be addressed urgently. Exploitation is likely and impact is severe
Medium	Yellow	4.0 - 6.9	Moderate risk. Exploitation requires some conditions to be met or impact is limited
Low	Blue	0.1 - 3.9	Minor risk. Difficult to exploit or low impact if exploited
Informational	Gray	0.0	Not a direct vulnerability but a finding worth noting (e.g., information disclosure, best practice deviations)

note

Severity and CVSS score are independent fields. You can set a severity level without a CVSS score, or provide a CVSS score that does not strictly align with the severity level if your professional judgment warrants it.

CVSS Scoring

Hawkra supports CVSS (Common Vulnerability Scoring System) base scores as an optional numeric field on each vulnerability. The score is validated to be between 0.0 and 10.0 inclusive.

The CVSS score is stored as a decimal value, so you can enter precise scores like 7.5 or 9.8. While Hawkra does not enforce alignment between the CVSS score and the selected severity level, keeping them consistent is recommended for report clarity.

CVE and CWE References

Vulnerabilities can include external reference identifiers:

• CVE (Common Vulnerabilities and Exposures): Links your finding to a known, publicly disclosed vulnerability. Format: CVE-YYYY-NNNNN.
• CWE (Common Weakness Enumeration): Categorizes the type of weakness. Format: CWE-NNN. Example: CWE-79 for Cross-Site Scripting, CWE-89 for SQL Injection.

These identifiers improve traceability and help stakeholders cross-reference your findings with public vulnerability databases.

Linking Vulnerabilities to Assets

A vulnerability can be linked to one or more assets, reflecting which systems are affected. Each link (called a "vulnerability-asset link") tracks:

• The affected asset
• An optional specific port on that asset (e.g., the vulnerability affects the HTTP service on port 443)
• Remediation status per asset (since the same vulnerability may be fixed on one host but not another)
• Notes specific to this asset's instance of the vulnerability (encrypted at rest)

Adding an Asset Link

When linking a vulnerability to an asset:

1. Select the target asset from your workspace.
2. Optionally select a specific port/service on that asset where the vulnerability was observed.
3. Optionally add notes describing how the vulnerability manifests on this specific asset.

The link is created with an initial status of "Identified" and a timeline event is automatically recorded.

Removing an Asset Link

You can unlink an asset from a vulnerability at any time. This removes the association and its remediation history but does not delete either the vulnerability or the asset.

tip

When linking a vulnerability found on a specific service (e.g., a weak SSL cipher on port 443), always specify the port. This level of detail makes your reports more actionable and helps asset owners understand exactly what needs to be fixed.

Remediation Status Tracking

Each vulnerability-asset link has its own remediation status, allowing you to track progress independently per affected host. The status transitions are:

Identified --> Validated --> Remediated

Status	Description
Identified	The vulnerability has been discovered and documented. This is the initial status when a link is created
Validated	The vulnerability has been confirmed through additional testing or verification
Remediated	The vulnerability has been fixed and verified as resolved

Updating Status

When you change a link's status, a timeline event is automatically recorded with the old and new status values, the user who made the change, and the timestamp. This creates an auditable remediation history for each vulnerability-asset combination.

You can also update the encrypted notes on a link when changing its status, for example to document what remediation steps were taken or to record re-test results.

note

Status tracking is per asset link, not per vulnerability. A vulnerability affecting three assets can have different statuses on each -- for example, "Remediated" on two servers but still "Identified" on a third.

Encrypted Remediation Notes

Notes attached to vulnerability-asset links are encrypted at rest using the workspace's data encryption key (DEK). This protects sensitive remediation details such as:

• Exploitation proof-of-concept details
• Specific configuration changes applied
• Credentials or access paths used during validation
• Re-test methodologies and results

Notes are decrypted only when accessed by an authorized workspace member and are never stored in plaintext in the database.

Viewing Vulnerabilities

Workspace Vulnerability List

The main vulnerabilities view shows all vulnerabilities in your workspace with their severity, CVSS score, CVE reference, and creation date. You can use this view to get a high-level picture of your assessment findings.

Vulnerability Detail View

Clicking on a vulnerability opens its detail view, which includes:

• All vulnerability metadata (title, description, severity, CVSS, CVE, CWE, impact, fixes, reference)
• A list of all linked assets with their individual remediation statuses and decrypted notes
• The ability to link additional assets, update statuses, or modify the vulnerability itself

Key Actions

Action	Permission Required	Description
View vulnerabilities	View Vulnerabilities	See all vulnerabilities and their linked assets
Create vulnerability	Edit Vulnerabilities	Create a new vulnerability manually or from a template
Update vulnerability	Edit Vulnerabilities	Modify vulnerability details (title, severity, description, etc.)
Delete vulnerability	Edit Vulnerabilities	Permanently remove a vulnerability and all its asset links
Link to asset	Edit Vulnerabilities	Associate a vulnerability with an affected asset
Update link status	Edit Vulnerabilities	Change the remediation status on a vulnerability-asset link
Unlink from asset	Edit Vulnerabilities	Remove the association between a vulnerability and an asset
Save to library	View Vulnerabilities	Save a vulnerability as a Findings Library template
Create from library	Edit Vulnerabilities	Create a vulnerability pre-filled from a Findings Library template

Tips and Notes

• Bulk creation from scans: When importing scan results (Nessus, OpenVAS, ZAP), vulnerabilities are created automatically and linked to the appropriate assets. This is the fastest way to populate your vulnerability inventory.
• Findings Library workflow: Build a personal library of commonly found vulnerabilities to speed up manual assessments. Create the vulnerability from a template, then customize the description and remediation notes for the specific engagement.
• Reference URLs are validated: The reference field is validated to ensure it contains a properly formatted URL. Use it to link to vendor advisories, NVD entries, or internal knowledge base articles.
• Encrypted notes protect sensitive data: All notes on vulnerability-asset links are encrypted with the workspace's DEK. If your workspace encryption key is rotated, the notes are automatically re-encrypted.
• Audit trail: Every vulnerability operation (create, update, delete, link, unlink, status change) is logged in the workspace audit trail with the user, timestamp, and client IP address.
• Cascade on delete: Deleting a vulnerability removes all its asset links and associated timeline events. The assets themselves are not affected.
• Status is per-link, not per-vulnerability: There is no global "status" on a vulnerability itself. Status is tracked individually for each affected asset, because the same vulnerability may be at different remediation stages on different hosts.