Key takeaway
Map data flows and trust boundaries, attach a testable control to each risk, and rerun the check after remediation.
Model threats from the design stage
Map system components, sensitive assets, data flows and trust boundaries. For each boundary and operation, ask the team what could go wrong. STRIDE prompts review of spoofing, tampering, repudiation, disclosure, denial of service and elevation of privilege; an attack tree explores paths to a goal, while an abuse case examines harmful use of a legitimate workflow. Choose a method that fits the system, record likelihood and impact, assign an owner and mitigation, and revisit the model when architecture or dependencies change.
Identify the asset and flow
For example, map account data from browser to API to database.
Examine the boundary
Record identity, authorization, untrusted input and component-compromise risks.
Verify the control with a test
Assign an owner, mitigation and retest for each high risk.
Core defenses against injection, SQLi and RCE
Injection occurs when untrusted input is interpreted as SQL, shell or another interpreter’s code. For example, concatenating a username into a login query can turn input into SQL syntax; a parameterized query keeps it as a value, not code. Add server-side allow-list and type checks as another layer. Avoid invoking a shell where possible; otherwise pass arguments separately and restrict privileges. For deserialization, accept only expected types and avoid constructing arbitrary objects; review memory safety and bounds checks. RCE can execute code inside a compromised process, so patch exposed services, restrict execution privileges and outbound connections, and exercise detection and recovery.
In-band SQLi
The application returns results over the same channel; error-based and UNION-based cases fit here.
Blind SQLi
When results are not shown directly, an attacker may infer them from boolean response differences or timing.
Out-of-band SQLi
Data may leave through a separate DNS or HTTP connection from the database server; restrict egress and database privileges.
Different tests find different weaknesses
SAST flags risky code patterns without running the application; review false positives and unreachable paths manually. SCA checks dependencies against known vulnerabilities, while an SBOM records the components in an application. DAST sends external requests to a running application and looks for authentication, configuration, XSS and injection issues, limited to the routes and roles exercised. IAST can combine runtime observation with code context, but sees only tested flows. OWASP Top 10 is a useful starting point; test access control, injection, cryptography, XSS and misconfiguration risks in your own system. Unit tests are easier to repeat when isolated from external services and databases; integration tests check module boundaries and audit flows. Fuzzing explores edge cases with unexpected inputs. Define the tester’s prior knowledge as black-box, white-box or grey-box, and separately agree on target systems and permitted actions. Scans and penetration tests complement each other.
Evaluate runtime controls in application context
RASP observes execution context inside an application and can block requests or operations through configured rules. A WAF inspects HTTP traffic before it reaches the application. In a pilot, test support for your language and framework, blocking mode, latency, false positives and the update process. Exercise real application workflows and controlled attack simulations, and remediate code and configuration flaws identified during testing.
| Control | Where it acts | What to verify |
|---|---|---|
| SAST / SCA | On code and dependency changes | Coverage, false positives, remediation owner |
| DAST / penetration test | On a running service and its interfaces | Role and route coverage, safe test scope |
| WAF / RASP | At the network edge / within the app runtime | Compatibility, latency, blocking and audit |
Manage configuration and cloud controls as code
Change default credentials, disable unused services and ports, minimize access and IAM permissions, and protect data in transit and at rest. Scan Infrastructure as Code for cloud storage, security groups, APIs and identity rules before deployment; compare live settings with declared configuration to detect drift. Account takeover, excessive data sharing and exposed APIs can have wider impact in multicloud estates. A CNAPP approach may combine CSPM, CWPP and CIEM with IaC scanning; WAAP may connect WAF, bot and DDoS controls with API rate limiting. These are solution categories, so verify a specific product’s coverage. Document which platform layers the provider manages and which workload, identity, network and data controls remain with your team for the service model.
Track findings through remediation and retesting
For each finding, record the affected asset, evidence, risk, owner, safe interim mitigation and permanent fix. Prioritize using exploitability and potential impact, not a tool score alone. After remediation, rerun the same scenario, add related checks to CI and update the threat model where needed. For critical systems, review authentication, authorization and data flow with both automated tests and an independent review.