Security Assessment and Testing
Security Assessment and Testing asks how to produce evidence about controls and systems without confusing activity with assurance.
Core rules
- A vulnerability assessment identifies and ranks weaknesses; a penetration test safely exploits a scoped target to demonstrate impact. Both need authorization and rules of engagement.
- CVSS base score reflects intrinsic severity; temporal and environmental scores adjust for exploit maturity and local context. A high score does not automatically mean high business risk.
- SAST inspects source or bytecode without running it; DAST tests a running application; SCA finds vulnerable dependencies. Each covers different blind spots.
- Audits and control assessments test evidence against criteria; sampling must be defensible and coverage documented.
- Track findings through risk acceptance, remediation, or compensating controls, with retesting.
Worked example
A scanner reports a critical TLS issue on an internal test server. The analyst checks exposure: the server is not reachable from production networks and holds no real data, but it shares a certificate with a production endpoint. The finding is downgraded for the test host but escalated for certificate reuse. The reasoning separates scanner severity from asset criticality, reachability, and shared trust.
Traps
A clean scan is not proof of security-it may reflect scope or signature gaps. Do not run exploitation without written authorization. Do not treat CVSS as a complete risk score. A false positive is a reported issue that is not real; a false negative is a missed issue, often worse.