Part 3 of 4 in the "Security Testing Landscape" series
The previous two posts covered tools and humans that attack systems. This group is different: nobody attacks anything. These are humans (and a few platforms) inspecting your designs, code, configurations, and paperwork — with full access. Every single item here is white box; that's the group's signature.
The best way to remember them is by the question each one answers on the project timeline.
"Are we designing it right?" — Before You Build
Threat Modeling
A structured brainstorm at design time: for each component, how would an attacker abuse it? The output is a prioritized list of threats and mitigations — before a single line of code exists, when fixes are cheapest.
The frameworks you'll hear:
- STRIDE — the classic threat checklist: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege.
- PASTA — a risk-centric, seven-stage methodology that ties threats to business impact.
- DREAD — a scoring model for ranking threats: Damage, Reproducibility, Exploitability, Affected users, Discoverability.
Tools: Microsoft Threat Modeling Tool, OWASP Threat Dragon, IriusRisk
Architecture / Design Review
Security engineers walk the diagrams and data flows: where are the trust boundaries, is authentication centralized, are secrets in a vault, does a frontend talk directly to a backend when it shouldn't. If you've ever defended an architecture diagram in front of a senior reviewer, you've lived this one.
References: cloud well-architected security pillars, OWASP ASVS
"Did we build it right?" — During and After the Build
Secure Code Review (Manual)
A human reads the code — especially auth logic, crypto usage, and input handling — catching design-level flaws that automated SAST cannot, like "this check can be bypassed by calling the API endpoints in a different order." Tooling assists (Semgrep, CodeQL, PR review workflows), but the value is the brain.
Configuration Review / Hardening Assessment
Compare actual server, database, and cloud settings against a hardened baseline: TLS versions, open ports, default accounts, logging enabled. The gold-standard baselines are the CIS Benchmarks and DISA STIGs.
Tools: CIS-CAT, Nessus compliance scans, Azure Policy
"Are we running it right?" — Continuously
Cloud Security Posture Assessment
The configuration review idea, applied to your entire cloud estate, continuously: public storage, over-permissive IAM, missing encryption, exposed endpoints — all scored against benchmarks in near-real time.
Tools: Microsoft Defender for Cloud (secure score), Prisma Cloud, Wiz, Orca
"Can we prove it to outsiders?" — When Auditors Arrive
Security Audit / Compliance Assessment
An external auditor checks whether you actually follow a standard — through evidence, policies, interviews, and screenshots. The output is a certification or findings report, never an exploit.
The standards you'll meet:
- ISO 27001 — certifies your information security management system
- SOC 2 — a trust-criteria report, the staple for SaaS vendors
- PCI DSS — mandatory if you touch card data
- HIPAA / GDPR — health data and personal data regulations
Tools: GRC platforms like Vanta, Drata, ServiceNow GRC — but mostly document review.
"Are we spending money right?" — Above Everything
Risk Assessment
The business-level exercise that sits on top of all of it: list assets → identify threats → score likelihood × impact → prioritize. This decides where the security budget goes and feeds every other activity on this page.
Frameworks: ISO 27005, NIST 800-30, and FAIR if you want risk quantified in actual currency.
Tools: honestly, spreadsheets — or a GRC platform if you're fancy.
The Timeline Recap
| Question | Activity | When |
|---|---|---|
| Designing it right? | Threat Modeling, Architecture Review | Before build |
| Built it right? | Code Review, Config Review | During/after build |
| Running it right? | Cloud Posture Assessment | Continuously |
| Proving it? | Compliance Audit | Audit season |
| Spending right? | Risk Assessment | Always, above all |
Remember: the testing groups attack; this group inspects with full access. Both are necessary — inspection finds what attacks miss, and attacks prove what inspections suspect.
Final post in the series: the cloud alphabet soup — CSPM, CWPP, CIEM, CNAPP, and EASM.
Top comments (0)