Weakness, vulnerability, and exploit
A weakness is a condition in software, configuration, design, or operation that can contribute to a security failure. A vulnerability is a weakness that an actor can use in a stated system and environment to violate a security property. An exploit is the method or artifact that exercises that vulnerability. Exposure describes whether an actor can reach the required interface and satisfy the exploit preconditions.
These terms are related but not interchangeable. A parser defect can exist without being reachable from an untrusted input. A reachable defect can still require a privilege or system state that the expected attacker does not have. A public proof of concept can increase practical exploitability without changing the underlying weakness.
Exploit path and preconditions
Model the complete path from actor to impact. Identify the entry point, required identity or network position, controlled data, parser or operation, vulnerable state, execution context, authority gained, and protected asset. Each step has a precondition. A control can break the path by removing reachability, rejecting the input, eliminating the weakness, reducing the execution authority, or containing the outcome.
Patch priority cannot come from a severity label alone. Consider whether the vulnerable component is deployed, reachable, enabled, exposed to the actor, and running with useful authority. Also consider active exploitation, available mitigations, affected data, recovery cost, and the confidence of the evidence.
Remediation and verification
Prefer a fix that removes the weakness class. Replace string-built commands with structured APIs. Replace unsafe parsers with data-only formats. Use a memory-safe implementation where practical. If a complete fix is not ready, reduce exposure with a narrow route, feature disablement, isolation, or input constraint. Treat this as temporary risk reduction.
Verify the fix at three levels. Reproduce the original failure. Test nearby variants and alternate paths. Confirm that the deployed artifact and configuration contain the fix. Add a regression test that observes the security result, not only the absence of one error message.
Failure and limits
A vulnerability scanner can miss business logic, alternate routes, state-dependent behavior, and new weakness classes. A CVE record does not prove that a specific deployment is exposed. The absence of a CVE does not prove that custom code is safe. A gateway can reduce reachability while the vulnerable upstream remains exploitable from another path.
Pomerium boundary
Pomerium can require identity and policy before a caller reaches a protected route. It can reduce public exposure and record access attempts. It does not repair a vulnerability in the application, dependency, parser, operating system, or deployment. The operator must close direct paths, patch affected components, test the deployed result, and contain the authority of the vulnerable service.
Evaluation checklist
- Can you name the weakness, reachable interface, attacker-controlled input, required preconditions, and violated security property?
- Is the affected component and version present in the deployed artifact?
- Can the attacker reach it through any direct, internal, administrative, or recovery path?
- Does the remediation remove the weakness or only reduce exposure?
- Does a regression test cover the original exploit path and nearby variants?
- Is the temporary mitigation owned, monitored, and scheduled for removal?
