Vulnerability Assessment

Vulnerability Assessment

An assessment answers a narrow, honest question: what weaknesses can be found in this system, by a systematic sweep, without breaking it. It is not a penetration test, which actively exploits; it confirms each finding with the least intrusive evidence and stops there.

It is broader than security-audit, which reads the implementation. An assessment covers the running system, its configuration, its dependencies and its exposed surface, and it ends in a remediation plan with owners, not a list.

1. Authorization and scope

Per security-core, the system is the user's own or in a written scope. An assessment sends some traffic at a running system, so ownership is confirmed and the scope is named before anything runs.

owned system      proceed; name the environment, prefer staging over production
written scope     proceed inside it, not one host beyond
neither           refused; offer the code-level audit instead
production caveat  a non-intrusive assessment is safe, but rate limits, WAFs and
                  alerting will react; coordinate so the assessment is not read
                  as an attack

2. Enumerate the attack surface

Before checking anything, know what there is to check.

entry points   every route, endpoint, form, upload, API, webhook, subdomain,
               and open port in scope
authentication where identity is established, and every unauthenticated surface
data flows     what data enters, where it is stored, what leaves
dependencies   the resolved tree, per dependency-security
configuration  the deployed configuration: headers, TLS, exposed services,
               default credentials, verbose errors, directory listings
trust boundaries   from the threat model if one exists; built here if not

An assessment that checks only the pages linked from the homepage misses the admin endpoint, the legacy API and the forgotten subdomain, which is where the finding usually is.

3. Check against the weakness classes

Walk the surface against the standard classes, using security-audit's twenty-four points as the code-level spine and adding the running-system checks.

identity/access   the authentication, authorization and session checks from the
                  respective skills, against the live system
injection         inputs reaching a dangerous sink, confirmed non-destructively
exposure          data returned that should not be, verbose errors, directory
                  listings, metadata leaks, secrets in responses or source maps
configuration     missing security headers, weak TLS, open management ports,
                  default credentials, debug endpoints reachable
dependencies      known advisories, re-ranked by reachability
business logic     the flows where the rules, not the code, are the weakness:
                  price manipulation, quantity abuse, step-skipping

4. Confirm without breaking

A candidate finding is confirmed with the least intrusive evidence that establishes it is real, and no more.

confirm       a reflected value that is not encoded: show it reflected, do not
              deploy a worm
confirm       an unscoped object: read one record that is not yours, do not
              enumerate the table
confirm       an injection: a payload that proves the sink is reached (a benign
              marker), never one that drops data or runs a shell
stop          at proof of reachability; exploitation for depth is
              authorized-pentesting, not this skill
never         a destructive confirmation on a system in use

5. Rank and plan remediation

rank          every confirmed finding on the security-core scale, by reachability
plan          each finding gets a remediation, an owner and a fix-or-accept
              decision; a report that stops at findings is half-done
prioritise    critical and high first; a long tail of low findings does not
              outrank one reachable critical
retest        a named retest list, so a fix is verified, not assumed

6. The report

scope         what was assessed, on what revision or environment, by what method
findings      each with severity, reachability, evidence, and remediation
what was not found   the classes checked that were clean, so the report says what
              was covered, not only what failed
residuals     accepted findings with their owner and compensating control
retest        the list to re-run after remediation

The report never says the system is secure. It says these classes were checked, these are the results, on this system, by this method.

7. Prohibitions

• Never assess a system without ownership or a written scope on record.
• Never confirm a finding destructively on a system in use.
• Never exploit for depth; confirmation stops at reachability.
• Never report findings without a remediation plan and owners.
• Never omit the surface that is not linked from the front door.
• Never conclude the system is secure; report coverage and results.
• Never run a noisy assessment against production without coordinating so it is not mistaken for an attack.

8. Protocol

1. Confirm ownership or scope; name the environment.
2. Enumerate the full attack surface, including the unlinked and forgotten.
3. Walk the weakness classes against the surface, using security-audit's points as the code-level spine.
4. Confirm each candidate with the least intrusive evidence; stop at reachability.
5. Rank every confirmed finding by reachability on the security-core scale.
6. Write a remediation for each, with an owner and a fix-or-accept decision.
7. Produce the report: scope, findings, what was clean, residuals, retest list.
8. After remediation, run the retest list and record the results.

9. Auto-critique

Score from 0 to 5: ownership or scope confirmed, surface enumerated beyond the obvious, weakness classes walked systematically, each finding confirmed non- destructively and stopped at reachability, findings ranked by reachability, every finding has a remediation and an owner, the report states coverage and never claims security, a retest list exists.

Threshold: no axis below 3, average at least 4. A destructive confirmation on a live system, or a claim that the system is secure, is an automatic zero.

10. Interfaces

• Upstream: security-core for posture and severity, security-audit for the code-level twenty-four points, threat-modeling for the surface and boundaries.
• Downstream: authentication-security, authorization-design, session-security, security-headers, dependency-security own the remediation of their classes; authorized-pentesting takes a confirmed finding further only under authorization.
• Lateral: test-reporting for the report format, decision-records for accepted residuals, release-readiness when the assessment gates a release.