AIS-04 — Secure Application Design and Development

Every framework that asks this

Answer AIS-04 once and it typically satisfies the equivalent control elsewhere. Altitude and confidence vary — a domain-level anchor is a starting point to verify, not an audited equivalence.

Full provenance and NIST 800-53 mappings: the framework crosswalk.

What the reviewer is really checking

The reviewer wants to know whether security is a gate in your development lifecycle or an afterthought bolted on before release. Behind 'Do you follow secure development practices?' sit concrete sub-questions: At what points in the SDLC do security activities happen, and are any of them blocking? Do you perform threat modeling or design review before build? What static (SAST), dynamic (DAST), and software-composition / dependency scanning tools run, at what stage, and does a failing scan actually stop a release or merely file a ticket? How are findings triaged by severity, and what is the SLA to fix a critical before it reaches production? For the interface side: how are your APIs authenticated and authorized, is there rate limiting and input validation, and how do you prevent broken object-level authorization? The reviewer is probing for named tooling and enforceable gates because those are falsifiable. 'Best practices' is unfalsifiable. They also want to know how you handle third-party and open-source components, since most modern breaches ride in through a dependency, and whether you track and patch known-vulnerable libraries.

What a truthful, defensible answer contains

A defensible answer maps security activities to lifecycle stages and says which ones block. Name the practices: design or architecture review and threat modeling before coding; the specific SAST, DAST, and dependency/SCA tools running in CI; and secrets scanning. State whether a failing gate blocks the merge or deploy, or is advisory. Describe your severity taxonomy and the remediation SLAs tied to it (for example criticals resolved before release, highs within a stated window), and how exceptions are approved and time-boxed. For interfaces, describe the API authentication and authorization model, input validation, rate limiting and abuse controls, and how object-level authorization is enforced so one tenant cannot read another's data. Cover your dependency posture: how you inventory components, monitor for newly disclosed vulnerabilities, and patch. The right level of detail names tools, stages, cadences, and owners without pretending to a maturity you lack. If a gate is advisory rather than blocking today, say so and state the compensating control, rather than implying enforcement you do not have.

Make it traceable

Tie the answer to artifacts a reviewer could inspect. Point at the CI pipeline configuration that shows the scan step and whether it is a required check, a sample scan report with findings and their dispositions, and the vulnerability-management policy that defines severities and SLAs. Reference a secure-SDLC or secure-coding standard document, and a recent penetration test that exercised the application and APIs, with its retest. The Promise-to-Proof line is that 'we gate releases on SAST/DAST' resolves to a pipeline definition plus a report, and 'we fix criticals before ship' resolves to a policy and a ticket history, so the reviewer confirms the gate exists rather than trusting the sentence.

Answer patterns that hold up

• Map each security activity to its SDLC stage and state which activities block a merge or release versus which are advisory.
• Name the SAST, DAST, and dependency-scanning tooling and where in CI each runs.
• State the severity taxonomy and the remediation SLA per severity, plus how exceptions are approved and time-boxed.
• Describe the API authentication, authorization, input-validation, and rate-limiting model and how cross-tenant access is prevented.
• Describe how third-party and open-source components are inventoried, monitored for new CVEs, and patched.

Evidence that backs the answer

Red flags reviewers catch

• "We follow secure coding best practices" with no named tooling, gate, or cadence.
• Listing scanners without saying whether a failing scan actually blocks a release.
• "All code is reviewed" with no severity SLAs or exception handling described.
• Describing app security while saying nothing about API authentication or authorization.
• No mention of dependency or open-source vulnerability monitoring.

Sources

• CSA Cloud Controls Matrix v4 — Application & Interface Security (AIS) domain
• NIST SP 800-53 Rev. 5 — SA (System and Services Acquisition), incl. SA-11 developer testing
• ISO/IEC 27001:2022 — A.8.25 Secure development life cycle, A.8.28 Secure coding

Other Application & Interface Security controls