Conducting Application Security Audits
This domain tests whether you can follow 27034's traceability chain during fieldwork: from application security risk to selected ASCs, through implementation, to validation evidence.
Evidence and traceability
For each sampled application, trace: risk assessment → ASC selection → design and build artifacts → verification evidence → validation conclusion. Use interviews, document review, observation of build and deployment, code and configuration review, and test evidence review. Check design intent and operating effectiveness; sample releases or transactions rather than accepting one demonstration. Compare evidence with the ASC's prescribed verification guidance, and record evidence identifiers so another auditor can retrace your conclusion.
Worked example
ASC-AUTH-01 requires centralized authentication and a defined session timeout. The auditor reviews the design (SSO), code (timeout setting), test report (timeout tested) and production configuration (one legacy service still uses local accounts). Reasoning: the control is effective for most of scope but not all; the exception has no risk assessment or approval. Conclusion: partial implementation, and the validation claim is overstated. The finding cites the ASC requirement, the production configuration evidence and the missing exception record.
Traps
- Accepting dashboards or tool screenshots as proof of effectiveness.
- Testing only the happy path and not exception handling.
- Confusing code review with penetration testing; stay within competence.
- Sampling one environment or one release and generalizing.
- Ignoring APIs, third-party components and inherited controls.