Coverage and Prioritisation of Security Testing
🌟 Objective
To define which components, functionalities and interfaces must be tested, with what depth and frequency, and with what type of test, based on:
- The application's risk level and criticality;
- Frequency of change and external exposure;
- History of previous flaws or findings;
- Security dependencies on other systems.
Coverage without prioritisation leads to waste. Prioritisation without coverage leads to a false sense of security.
🔍 What coverage and prioritisation in security are
Coverage refers to the percentage of the system that is covered by security testing - including:
- Source code;
- APIs and endpoints;
- Functional flows;
- Integrations and dependencies.
Prioritisation defines what to test first or more intensively, based on:
- Likelihood of exploitation;
- Impact in the event of a flaw;
- Ease of testing;
- Regulatory or reputational risks.
💡 A risk x test-frequency matrix helps to operationalise the strategy.
⚙️ How to apply
- Map attack surfaces and exposed interfaces (e.g. public APIs, management panels);
- Classify areas by functional criticality and security impact;
- Define a minimum test frequency per risk category (e.g. monthly for L3, half-yearly for L1);
- Flag coverage gaps (e.g. untested endpoints, uninstrumented code);
- Adjust test depth according to the type (e.g. fuzzing for parsers, DAST for external interfaces);
- Review the coverage map periodically with the technical and security teams.
✅ Good practices
- Include security coverage in the quality criteria;
- Track real coverage with metrics (e.g. % of APIs tested);
- Prioritise new, critical or recently changed functionalities;
- Use tagging by component and criticality in the tests;
- Assess the effective coverage of automated tests (not just their presence);
- Validate whether regressions and findings are being reviewed in the highest-risk areas.
📎 Cross-references
| Document | Strategic relevance |
|---|---|
| Chapter 01 - Risk Management | Defines classification and criticality criteria |
| Chapter 02 - Requirements | Defines what must be validated and why |
01-sast.md to 04-fuzzing.md | Test types applicable to prioritised areas |
05-validacao-regressao.md | Helps define persistent targets |
08-gestao-findings.md | Relates findings to tested or untested areas |
🧩 Security test coverage is not binary - it must be contextual, proportional and oriented to real risk. Covering what matters is as vital as testing well.