# Vulnerability Assessment > Vulnerability Assessment - Skill: `handsomeboy990/vulnerability-assessment` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add handsomeboy990/vulnerability-assessment` - Raw SKILL.md: https://api.skillmd.com/api/skills/handsomeboy990/vulnerability-assessment/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Security - Author: Handsomeboy990 (https://skillmd.com/u/handsomeboy990) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/handsomeboy990/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.