certslothcertsloth
CISA/Topic 05

ISACA / Professional

Secure Software Lifecycle and Supply Chains

3 min read5 recall promptsReviewed 2026-10-10

Memory hook: Build the control into the path that ships code.

Must remember

Security starts in requirements and design, continues through implementation/testing and remains necessary during operation and retirement. Waterfall, Agile and DevSecOps change delivery organization, not the need for risk decisions. Maturity models assess repeatability and capability; they do not certify that a particular application is vulnerability-free.

Define abuse cases and trust boundaries before coding. Use server-side authorization for every protected object/action, parameterized queries, context-appropriate output encoding, bounds checking, safe memory patterns and structured error handling. Client-side validation improves usability but is not a trusted enforcement point. Prevent secrets from entering source code, build logs and artifacts.

Secure the development ecosystem: repositories, branch protections, reviewers, build runners, dependencies, artifact registries, signing keys and deployment identities. Separate build from approval/deployment authority where needed. An SBOM inventories components; provenance records how an artifact was produced; signatures establish integrity and issuer within a trust system. None alone proves the software has no vulnerability.

Use SAST, DAST, SCA and appropriate manual review at complementary stages. Verify fixes with regression and abuse tests. Threat modeling and architecture review catch issues that scanners may miss. Purchased, open-source, SaaS and custom software all require risk assessment, support/patch obligations and exit planning.

AI-enabled development and applications add untrusted generated code, prompt injection, sensitive-data leakage, model supply-chain risks and excessive agent permissions. Treat generated output as untrusted; validate code and data before use. Retrieval authorization must follow the user's permissions, and tool execution needs explicit, narrow authority. Monitor model/application changes as production changes.

Assess software security with meaningful outcomes: escaped defects, time to remediate, verified control coverage and supply-chain integrity. A pipeline that merely runs a scanner without acting on results is not effective assurance.

Choose under exam pressure

Requirement Choice and reason
Prevent a dependency compromise from reaching production Control sources, versions, provenance, scans and release authority.
AI agent can execute business actions Constrain tools/identity and validate each high-impact action.
Purchase a SaaS application Assess security, data handling, support, contracts and exit capability.

Traps

  • Open source is not automatically safe or unsafe.
  • A signed malicious artifact remains malicious.

Active recall

1. What does an SBOM provide?

An inventory of software components, not proof of safety.

2. Why is browser-only authorization insufficient?

Attackers can bypass the client and call server APIs directly.

3. What is prompt injection’s key trust problem?

Untrusted content is treated as instructions that influence model or tool behavior.

4. Why separate build and release authority?

A compromised build process should not automatically approve its own production deployment.

5. What should happen after a security fix?

Verification and regression tests, plus review for related instances and root causes.

Sources

CLOSE THE NOTES. EXPLAIN THE CHOICE.

How well could you recall it?

Your next review is based on this answer. Progress stays in this browser.

Search across every published topic.