VISA — Vulnerability Impact Scoring Automation

VISA — Vulnerability Impact Scoring Automation

Goal

The goal is to determine: impact based scoring

  1. Is it a vulnerability?
    Invested fix time is spent on vulnerabilities, not on other security bugs that are excluded.
  2. Is the impact critical?
    Determine the impact.
  3. Is it fixed?
    Sign-off confirms: I understand and approve the classification, the impact, and what was fixed.

Filtering and Scoring Vulnerabilities for First-Party Vulnerability Owners

1. Find a Suspected Vulnerability

A suspected vulnerability is found.

2. Determine the Security Bug Type

Vulnerability

Applies to code.

Protection Weakness

Applies to the system.
Do not fix it as a vulnerability.

Mitigation Exposure

Applies to the security control.
Do not fix it as a vulnerability.

3. Software Condition Classification

Manipulation Source — Cause

Input — User

No sanitation or limits.

Examples:

  • SQL injection
  • XSS
  • OS injection

Handovers

No sanitation between components or systems.

Examples:

  • Log4j
  • Directory traversal

Design

The login or design flow is wrong and can be bypassed.

4. Manipulation Technique

Concatenation

Appending malicious logic to existing code.

Embedding

Breaking parsing logic using a malformed structure.

Replacing

Substituting safe values with executable ones or replacing what is expected.

Examples:

  • Replacing tokens
  • Overriding due to configuration
  • Replacing the design flow

5. Verify That It Is Not a False Positive

Verify whether the following exist:

  • A manipulation source
  • A manipulation technique

If they do not exist, it is a possible false positive.

6. Software Behavior Classification

Classify the exploitation behavior that violates CIA.

Compute

  • Read configurations
  • Tamper
  • Install
  • Code execution

Data

CRUD actions on data types:

  • System
  • Service
  • PII

Service

  • Load
  • Random outage
  • Service down

Determine the impact that the bug allows.

7. Authentication and Authorization Context

Authorization

Determine the context and level of execution.

Authentication

Determine whether the attacker needs to be logged in.

  • CE
  • RCE

8. Determine the Exploit Level

CE

Fully exploitable and weaponized.

  • Condition
  • Behavior

PoC

Partly or minimally exploitable and weaponized.

Theoretical

A bug condition exists, but the behavior cannot be proven.

It is not a vulnerability, but we do not take risks, so it is treated as a vulnerability.

9. Determine the Impact Using VIS

Determine the vulnerability impact based on Vulnerability Impact Scoring.

10. Determine the Severity Level

Severity 1

Fix now.

  • Top priority
  • Potential Crisis Response

Severity 2

Fix soon.

  • Potential Emergency Response

Severity 3

Fix later.

  • Potential Incident Response

11. Fix Verification and Sign-Off Sanity Check

The vendor Security Engineer owns the vulnerability and signs off on the fix.

Verify that the fix addresses the condition—the manipulation—and not only the observed behavior.

Fix Verification

  • The fix addresses the condition and the behavior.
  • The fix addresses only the behavior—risk of F4F.
  • The manipulation technique no longer works after the fix.
  • The vulnerability is retested at the same exploit level as originally proven.
  • A minimum smoke test is performed.

Sign-Off

SE / PSIRT: ____________________

The sign-off confirms:

  • It is a vulnerability.
  • The scoring is correct.
  • It is fixed.
  • It is ready to publish.

12. If It Cannot Be Fixed

Use a compensating approach.

13. Publish

Publish the vulnerability using the:

Vulnerability Publication Impact Table

Publication method:

  • Public disclosure

download – claude version hacktica-visa-process-flow