Below is the complete arranged version of your text. I kept your terminology, definitions, and scoring logic as written. I only corrected spelling, grammar, punctuation, and structure, and added your framing note from this conversation.
First-Party Vulnerability Scoring
Framing
This framework is designed for the PSIRT Security Engineer.
It is not designed for Product Development Security, but Product Development may also use it if they wish.
This framework is designed to assist the Security Engineer in verifying:
- That it is really a vulnerability that we need to fix.
- How critical the vulnerability is — its impact on customer assets.
- The priority of the fix — when should the vendor fix it: now, soon, or later?
- What was fixed — to prevent cases where the behavior was fixed rather than the condition.
- How to reflect the impact in the public disclosure.
Topics
The topics are ordered from A to I:
- A. Vulnerabilities and Definitions
- B. Software Condition Classification
- C. Software Behavior Classification
- D. Risk Classification
- E. Exploitation Context
- F. The Exploit Level
- G. Scoring Considerations
- H. Scoring Table
- I. Reflecting the Vulnerability in the Public Disclosure
- Vulnerabilities and Definitions
Definitions — do not change or add. Treat them as solid for now.
Vulnerability
A vulnerability is a security-implication bug that violates CIA.
Types
Vulnerabilities apply to code: an exploitable CIA violation caused by the software itself.
Code execution on assets that violates CIA is the definition of a vulnerability.
- Input
User or system input at the function, parameter, system service, or component.
Examples:
- SQLi
- XSS
- LFI
- Command injection
- Handovers
Handovers between components or system-wide.
Examples:
- Directory traversal
- SSRF
- Design
- Logical issue
- Wrong flow
- Insecure design
Software Condition
A software defect that accepts manipulated input.
Software Behavior
The possible changes that can be made — code execution and exploitability.
Exploitation Phases
- Vulnerability
The condition and the manipulation source or cause:
- Input
- Handover
- Design
- Behavior
Exploitation — the actions that can be performed and that violate CIA.
- Operational
The damage.
This is beyond the scoring. It is included only as a phase to mention.
- Software Condition Classification
Manipulation Source — Cause
Input — User
No sanitation and no limits.
Examples:
- SQLi
- XSS
- OS injection
Handovers
No sanitation across components or across the system.
Examples:
- Log4j
- Directory traversal
Design
The login is wrong and can be bypassed.
Manipulation Techniques
These are important for understanding the fix that was made and for verifying what was fixed.
The PSIRT Security Engineer needs to know this.
Concatenation
Appending malicious logic to existing code.
Embedding
Breaking parsing logic using a malformed structure.
Replacing
Substituting safe values with executable ones and replacing expected values.
In a design flow:
- Replacing tokens
- Overriding due to configuration
- Software Behavior Classification
Classification of behavior during exploitation — violating CIA.
Compute
- Read configurations
- Tamper
- Install
- Code Execution — CE
Data
CRUD actions on data types:
- System data
- Service data
- PII
Service
- Load
- Random outage
- Down
The authentication and authorization context is addressed in the exploitation-context table.
- Risk Classification
Compute Plane
- Data Plane CE
- Control Plane CE
This is not authentication or authorization.
Data Confidentiality
By custom definition, this can apply to system data if it is mission-critical.
It can also apply to business data if the business is military, government, or similar.
Mission-Critical Service
A service can be mission-critical because it is the main business.
It may or may not contain confidential data.
- Exploitation Context
Exploitation Permission
In which context does the exploit run?
Authorization
Authorization is the context of execution and the level of execution:
- Root privileges
- High privileges
- Medium privileges
- Low privileges
This is needed to understand whether the change in behavior can actually run with the top system privileges.
Authentication
Does the attacker need to be logged in?
If login is required, then only the following privilege escalations apply:
- Medium to High
- High to Root
If the attacker is logged in as Root, it is not a vulnerability. The question is how much the attacker can escalate their privileges.
Note: If the attacker is already authenticated, then you already have a problem.
Unauthenticated
Unauthenticated means that the exploit can be executed without login.
This means that the attacker can perform remote code execution.
This is the highest severity because it has a high chance of becoming a KEV.
If the exploit runs with Root or High privileges, it is Critical.
This does not mean unauthenticated access to the environment itself.
It applies only to a vulnerability where the attacker can run the exploit remotely, over the web. It excludes local or physical access.
Scoring Note
Authorization and authentication can reduce the criticality, but by default, they do not affect the score.
The score is determined by the impact table.
Authorization and authentication are therefore more relevant as considerations for becoming a KEV than for directly affecting the score.
You do not always know the permission context, but you usually know whether authentication is required.
Authorization Contexts
- Authorization — attacker login privileges: the privileges the attacker has when logging in.
- Authorization — vulnerability context: the context in which the exploit is executed, from Low privileges to Root privileges.
This is important and can reduce the vulnerability score.
Authentication and Authorization Table
| Vulnerability Execution Context | Unauthenticated — RCE | Authenticated CE — Low or Medium Attacker Privileges | Authenticated CE — High Attacker Privileges | Authenticated CE — Root Attacker Privileges |
| Root privileges | Critical | High | High | Not a vulnerability |
| High privileges | High / Critical | Medium / High | Not a vulnerability | N/A |
| Medium or Low privileges | High / Medium | Not a vulnerability | N/A | N/A |
- The Exploit Level
Not all vulnerabilities allow full code execution.
CE — Code Execution
This is the classical vulnerability with full code execution.
Condition
The condition exists.
Behavior
It changes the expected behavior and allows code execution.
Vulnerability
The two together — condition and behavior — violate CIA and therefore create a vulnerability.
PoC — Proof of Concept
Condition
The condition exists.
Behavior
Limited options exist to modify the expected behavior.
The behavior violates CIA and therefore creates a vulnerability.
Theoretical
Condition
The condition exists.
Behavior
The testing performed cannot show a change in behavior.
However, this is still a potential vulnerability.
The fact that no code execution was found does not mean that it cannot be done in some cases.
- Scoring Considerations
Scoring
The default is a Critical vulnerability.
Base Criticality
Compute
Any CE that allows the attacker to perform the following is Critical:
- Read
- Tamper
- Install
Data
Any CE that performs CRUD actions on PII is Critical.
Compute
Any CE that causes the site to go down is Critical.
Risk
The fact that the actions above can be performed does not necessarily mean that the vulnerability has a real risk.
The actual risk depends on the definition of the system.
The base criticality above can be enough to justify a fix, but the dimensions below should also be considered.
Mission-Critical Service
If the service is mission-critical, the vulnerability is Critical.
Confidential Data
If the data is confidential, the vulnerability is Critical.
This mostly applies to PII, but it is not limited to PII.
Publicly Accessible Compute
If the compute is publicly accessible, CE on the Data Plane or Control Plane is Critical.
- Scoring Table
This needs to become a calculator or another method for deciding the following.
Vulnerability Scoring
| Dimension | Classification |
| Condition — Manipulation Source | Input; Handovers; Design |
| Condition — Concatenation | Appending malicious logic to existing code |
| Condition — Embedding | Breaking parsing logic using a malformed structure |
| Condition — Replacing | Substituting safe values with executable ones; replacing expected values; replacing tokens; overriding due to configuration |
| Behavior — Compute | Read configurations; tamper; install; CE |
| Behavior — Data | CRUD actions on system data, service data, or PII |
| Behavior — Service | Load; random outage; down |
| Risk — Compute Plane | Data Plane — CE on the data path; Control Plane — CE on the configuration utility |
| Risk — Data Confidentiality | Confidential; secrets; unclassified |
| Risk — Software Mission Statement | Critical; important; low |
Calculator Question
Do impact and risk need to be multiplied?
Or should specific combination rules be used, such as:
If this condition and this risk are present, then the result is Critical.
The Bottom Line — The Goal
To determine whether the vulnerability has a meaningful and tangible impact that can really happen.
The concept is to focus on Critical first.
The idea is to start with Critical and then reduce the score based on the other dimensions.
The Result
The result should look something like this:
Criticality — To Fix or Not to Fix
Critical and High
Critical and High vulnerabilities must be fixed.
Critical vulnerabilities come first in the fix queue.
High
High vulnerabilities should be fixed soon, but Critical vulnerabilities come first.
Medium and Low
Medium and Low vulnerabilities should be fixed later.
They are not urgent at this point in time.
Will Not Fix
Despite the scoring, the vulnerability cannot be fixed.
This result is excluded from the scoring for now.
- Reflecting the Vulnerability in the Public Disclosure
Vulnerability Publication Impact Table — Public Disclosure
| Impact | Sev 3 — Medium | Sev 2 — High | Sev 1 — Critical |
| Service | Elevated load or slow response | Performance degradation or partial functionality loss | Service unavailable or core functionality down |
| Data | Limited information disclosure or minor bypass | Data exposure, partial corruption, or modification | Confidential data breach or confidential data leak |
| Compute | Limited system execution or configuration view | Individual node or component compromise | Full-system or environment takeover |
Download calc – Version 1 1hacktica-first-party-vul-scoring
Download calc – Version 2 2 hacktica_first_party_vulnerability_calculator