Software security is not a single scan at the end of development. A design can expose sensitive data before any code is written. A clean source scan can miss a vulnerable dependency or an unsafe production setting. A functioning application can still be delivered through a compromised build pipeline.
This Quick Review uses the CISSP 2024 exam outline, Domain 8 objectives 8.1 through 8.5. For broader explanations, use the Domain 8 study guide.
Decision rule: First identify the risk and lifecycle stage. Then choose a safeguard that can address that risk and produce evidence of its effectiveness.
1. Find the decision before choosing a tool
| Scenario clue | Start with | Reason |
|---|---|---|
| New payment feature; unclear trust boundaries | Security requirements and threat modeling | Identify assets, misuse paths, and design controls before implementation. |
| Developer may have introduced an unsafe code pattern | Code review and Static Application Security Testing (SAST) | Inspect source or related artifacts without needing the application to run. |
| Deployed web application may mishandle requests | Dynamic Application Security Testing (DAST) | Exercise the running application from its exposed interface. |
| Application includes a vulnerable third-party package | Software Composition Analysis (SCA) | Inventory dependencies and compare them with known vulnerabilities and policy. |
| Release could be altered after code review | Protected build and release pipeline | Control who can build, change, sign, approve, and deploy artifacts. |
| Vendor delivers closed-source software | Acquisition security assessment and contract requirements | Require evidence and assurances suited to the software's risk and use. |
2. Put security in the correct lifecycle stage
The Software Development Life Cycle (SDLC) covers software requirements, design, implementation, testing, release, operation, change, and retirement. Development methods such as Agile, Waterfall, DevOps, and DevSecOps organize the work differently; none removes the need for security decisions.
- Requirements: Identify sensitive data, abuse cases, compliance duties, acceptable risk, and security acceptance criteria. Specify who can approve exceptions.
- Design: Model threats, trust boundaries, privileged operations, and failure modes. Choose secure architecture and review changes to the design.
- Implementation: Apply coding standards, peer review, approved dependencies, and safeguards for secrets and developer environments.
- Verification: Use complementary code, dependency, and runtime tests. Triage findings, repair defects, and retest the fix.
- Release: Protect build identities, approve changes, verify artifact integrity, and retain traceable release evidence.
- Operations and change: Monitor vulnerabilities, configuration drift, and incidents. Patch supported versions and reassess after meaningful changes.
- Retirement: Revoke credentials, end access, preserve or dispose of data as required, and address unsupported components.
The National Institute of Standards and Technology (NIST) Secure Software Development Framework (SSDF) organizes practices into preparing the organization, protecting the software, producing well-secured software, and responding to vulnerabilities. Use it to structure a program across the lifecycle, not as a substitute for risk decisions.
3. Choose the test by what it can observe
Static Application Security Testing (SAST) examines source code or other non-running application artifacts for possible weaknesses. It can run early and often. Static analysis cannot prove that an application behaves securely in its deployed environment.
Dynamic Application Security Testing (DAST) tests a running application's externally observable behavior. It can reveal failures in request handling and runtime behavior, but usually has limited insight into which source line caused a defect.
Interactive Application Security Testing (IAST) observes application behavior from inside the running application while tests exercise it. It combines runtime observation with internal context, but requires suitable instrumentation and test coverage.
Software Composition Analysis (SCA) identifies third-party libraries and components, their versions, and known dependency risks. It does not replace secure coding review or prove that a reported vulnerability is exploitable in the deployed system.
- Manual code review helps identify business-logic flaws and authorization mistakes that automated tools may not understand.
- Threat modeling examines likely misuse and trust boundaries during design and after architectural changes.
- Penetration testing evaluates exploitable paths within an authorized scope; a time-limited test cannot certify an entire lifecycle as secure.
- Secret scanning looks for exposed credentials or tokens in repositories and other defined locations. It complements access control and credential rotation.
Exam clue: “Source pattern” suggests static analysis. “Running application” suggests dynamic testing. “Known vulnerable library” suggests composition analysis. “Abuse of an allowed workflow” calls for manual logic and authorization review.
4. Secure the delivery pipeline, not only the code
A Continuous Integration and Continuous Delivery (CI/CD) pipeline can run tests and package releases, but it also holds powerful access to repositories, dependencies, build artifacts, secrets, and deployment systems.
Choose controls that match the pipeline risk:
- Protect source repositories with appropriate access, peer review, and branch or change approval rules.
- Restrict build and deployment service identities. Prefer temporary credentials and separate duties for sensitive promotions.
- Control and monitor changes to build scripts, runners, dependencies, and infrastructure configuration.
- Preserve artifact integrity and provenance so an approved source change can be connected to the release that was actually deployed.
- Use a Software Bill of Materials (SBOM) to document component inventory. It improves visibility; it does not by itself demonstrate that components are safe.
- Set clear gates for serious findings, record exceptions with an owner, and verify remediation before releasing when the risk demands it.
A successful SAST check cannot protect an artifact that is replaced later. Strong build controls and provenance help close that gap.
5. Use coding and API safeguards for the weakness
Secure coding standards turn requirements into repeatable implementation rules. Choose them for the failure mode:
- Untrusted input: Validate input against expected formats and use parameterized database queries where appropriate.
- Output handling: Encode output for the destination context to reduce injection into a browser or other interpreter.
- Authorization: Check access on the server for each protected action or object; hiding a button does not prevent unauthorized API access.
- Secrets: Keep credentials out of source and logs, limit their privileges, and rotate exposed secrets.
- Error handling: Fail safely, log enough to investigate, and avoid disclosing internal details to the caller.
- Cryptography: Use reviewed libraries and sound key management rather than designing a new cipher.
An Application Programming Interface (API) needs its own authentication, authorization, input-handling, and monitoring decisions. Passing a general web scan does not prove that an API enforces object-level access correctly.
6. Evaluate software you buy, license, or integrate
CISSP objective 8.4 covers commercial off-the-shelf, open-source, managed, third-party, and cloud software. The organization's responsibility to assess risk does not disappear when another company wrote the code.
Before adopting software, determine data exposure, business criticality, integration privileges, patch commitments, supplier response processes, and exit options. Request appropriate evidence such as assessment results, support terms, component transparency, and incident-notification obligations. Verify that contract language reflects the actual operating arrangement.
After adoption, track security advisories, supplier changes, support status, and configuration drift. A vendor's general security claim is not evidence that a particular application, version, or integration meets your requirements.
7. Measure whether the safeguards work
CISSP objective 8.3 asks whether software security can be evaluated, not whether a dashboard has many green indicators.
Useful evidence can include approved requirements, reviewed changes, test coverage and results, verified remediation, vulnerability aging, exception ownership, signed release records, and incident lessons. Investigate what a metric leaves out before drawing a conclusion. A low finding count may indicate strong code, weak testing, inadequate coverage, or an unexamined system.
The accountable risk owner decides on residual risk under organizational policy. Developers, security reviewers, and operators supply evidence; no automated scanner grants risk acceptance by itself.
8. Scenario comparisons
A new API permits a user to retrieve another customer's records. The missing safeguard is a server-side authorization check for the requested object. Add design and code review for the access rule, then test the affected behavior. Scanning only the dependency list would miss the core problem.
A reviewed release has a different checksum when it reaches production. Investigate artifact provenance, build permissions, and deployment integrity. More source scanning alone does not establish whether the deployed artifact matches the approved build.
A third-party library has a serious advisory, but the vendor claims the feature is not used. Establish which version is present, whether the vulnerable code is reachable, and what mitigations exist. Record an approved treatment rather than assuming the advisory automatically proves exploitation or is irrelevant.
A software supplier will stop supporting a critical component. Identify affected systems, contractual obligations, security exposure, upgrade paths, and an authorized replacement or retirement plan. Waiting for an incident is not a lifecycle strategy.
9. Common exam traps
- Security testing is not a single finish line. Design review, testing, controlled releases, and maintenance protect different stages.
- SAST and DAST see different evidence. Neither guarantees absence of vulnerabilities.
- SCA checks components. It is not a substitute for reviewing the application's own access-control logic.
- A passing pipeline is not automatically a trusted pipeline. Its configuration, identities, and artifacts also need protection.
- Supplier responsibility differs from organizational accountability. Buying software transfers development tasks, not all risks from using it.
- A metric is evidence, not approval. A risk owner must still make the authorized treatment decision.
10. Rapid review grid
| Need | Look for |
|---|---|
| Prevent design misuse | Security requirements, threat modeling, design review |
| Find source-level weaknesses | Peer review, SAST |
| Test a running interface | DAST, authorized penetration testing |
| Observe runtime with internal context | IAST with instrumentation |
| Identify vulnerable dependencies | SCA, component inventory, advisories |
| Trust a release | Change approval, protected builds, artifact provenance |
| Evaluate acquired software | Supplier assessment, contracts, monitoring, exit plan |
| Show controls work | Test evidence, remediation verification, audit logs, risk decisions |