Domain 8 Master Cheat Sheet – Part 2

Secure Software Development & Application Security

Why Secure Coding Matters

Software vulnerabilities are one of the leading causes of data breaches.

Common consequences include:

• Data theft

• Ransomware

• Financial fraud

• Privilege escalation

• Remote code execution

• Regulatory violations

• Service disruption

The objective is not to eliminate every bug, but to reduce exploitable security weaknesses through secure design and development.

Secure Coding Principles

Every secure application should follow these core principles.

✔ Validate all input

✔ Encode all output

✔ Authenticate users securely

✔ Enforce authorization

✔ Protect sensitive data

✔ Log security events

✔ Fail securely

✔ Minimize attack surface

✔ Handle errors safely

✔ Apply least privilege

Input Validation

Never trust user input.

Validate:

• Length

• Format

• Range

• Type

• Allowed characters

Examples

• Email address

• Phone number

• Date

• Numeric values

Use allowlists (whitelists) whenever possible rather than blocking known bad input.

Server-Side vs Client-Side Validation

Output Encoding

Output should be encoded based on its destination.

Examples

• HTML encoding

• JavaScript encoding

• URL encoding

• XML encoding

• JSON escaping

Proper output encoding helps prevent Cross-Site Scripting (XSS).

Error Handling

Applications should fail securely.

Poor error messages reveal:

• Database names

• File paths

• Source code

• Stack traces

• Software versions

Instead

Provide generic user messages while recording detailed information in secure logs.

Secure Logging

Security logs should record:

• Authentication events

• Authorization failures

• Administrative actions

• Configuration changes

• Security exceptions

• Account lockouts

Logs should never contain:

• Passwords

• Encryption keys

• Session tokens

• Credit card numbers

• Sensitive personal information

Authentication

Authentication answers:

Common methods include:

• Passwords

• MFA

• Biometrics

• Certificates

• Smart cards

• Passkeys

• Hardware tokens

Authentication Best Practices

✔ MFA

✔ Password hashing

✔ Strong password policy

✔ Rate limiting

✔ Account lockout

✔ Session timeout

✔ Credential monitoring

Password Storage

Passwords should never be encrypted for storage.

Instead:

Store salted password hashes using strong password hashing algorithms.

Examples

• Argon2

• bcrypt

• PBKDF2

Authorization

Authorization answers:

Models include:

• DAC

• MAC

• RBAC

• ABAC

Authorization should always occur after successful authentication.

Authentication vs Authorization

One of the most frequently tested CISSP concepts.

Session Management

Secure session management prevents session hijacking.

Best practices

• Secure cookies

• HttpOnly

• Secure flag

• Session expiration

• Idle timeout

• Session regeneration after login

Secrets Management

Applications often require:

• API keys

• Database passwords

• Certificates

• Encryption keys

• Cloud credentials

Never:

• Hardcode secrets

• Store secrets in source code

• Commit secrets to Git

Use secure vaults instead.

Examples

• Azure Key Vault

• AWS Secrets Manager

• HashiCorp Vault

Cryptography in Applications

Applications should use encryption for:

• Data at rest

• Data in transit

• Password storage (hashing)

• Digital signatures

• API communications

Common algorithms

Encryption

• AES

Hashing

• SHA-256

• SHA-3

Asymmetric

• RSA

• ECC

Secure APIs

APIs have become primary attack targets.

Protect APIs using:

• Authentication

• Authorization

• TLS

• Rate limiting

• Input validation

• Logging

• API gateways

REST API Security

Best practices

✔ HTTPS only

✔ OAuth 2.0

✔ OpenID Connect

✔ JWT validation

✔ Least privilege

✔ Rate limiting

✔ Schema validation

Mobile Application Security

Protect:

• Local storage

• Credentials

• API communication

• Certificates

• Tokens

• Sensitive data

Avoid storing secrets directly within the mobile application.

Web Application Security

Common protections include:

• HTTPS

• CSP

• Secure cookies

• CSRF protection

• Input validation

• Output encoding

• WAF

Cloud Application Security

Protect:

• IAM

• APIs

• Secrets

• Containers

• Storage

• Logging

• Monitoring

Cloud security follows the Shared Responsibility Model.

Common Software Vulnerabilities

SQL Injection

Cause

Unsanitized database input.

Mitigation

• Parameterized queries

• Prepared statements

• Input validation

Cross-Site Scripting (XSS)

Cause

Untrusted output displayed by browsers.

Mitigation

• Output encoding

• CSP

• Input validation

Cross-Site Request Forgery (CSRF)

Cause

Authenticated users perform unintended actions.

Mitigation

• CSRF tokens

• SameSite cookies

• Re-authentication

Buffer Overflow

Cause

Memory exceeds allocated boundaries.

Mitigation

• Safe languages

• Bounds checking

• Compiler protections

Insecure Deserialization

Cause

Processing untrusted serialized objects.

Mitigation

• Validate data

• Restrict object types

• Prefer safer serialization formats

Broken Authentication

Examples

• Weak passwords

• Credential stuffing

• Session hijacking

Mitigation

• MFA

• Password policies

• Account lockout

Broken Access Control

Examples

• Privilege escalation

• Insecure direct object references

• Missing authorization

Mitigation

• Server-side authorization

• Least privilege

• RBAC/ABAC

OWASP Top 10

The CISSP exam expects familiarity with major application security risks.

Examples include:

• Broken Access Control

• Cryptographic Failures

• Injection

• Insecure Design

• Security Misconfiguration

• Vulnerable Components

• Authentication Failures

• Software Integrity Failures

• Logging Failures

• Server-Side Request Forgery (SSRF)

Understand the concepts rather than memorizing every item.

Secure Design Principles

Applications should be:

• Simple

• Modular

• Secure

• Testable

• Maintainable

• Scalable

Avoid unnecessary complexity.

Security Code Reviews

Code reviews identify:

• Logic flaws

• Hardcoded secrets

• Poor authentication

• Missing validation

• Weak cryptography

Peer reviews improve software quality before testing.

Defensive Programming

Developers should assume:

• Input is malicious

• Networks are hostile

• Users make mistakes

• Attackers look for weaknesses

Applications should respond safely under unexpected conditions.

Security Architecture for Applications

A secure application typically includes:

User
   ↓
Web Application Firewall (WAF)
   ↓
Load Balancer
   ↓
Web Server
   ↓
Application Server
   ↓
Authentication Service
   ↓
Database

Security controls exist at every layer.

Secure Development Best Practices

✔ Validate input

✔ Encode output

✔ Hash passwords

✔ Protect secrets

✔ Use MFA

✔ Enforce authorization

✔ Log security events

✔ Encrypt sensitive data

✔ Review code

✔ Continuously improve

Common CISSP Exam Traps

Trap 1

Client-side validation provides security.

Incorrect.

Server-side validation is mandatory.

Trap 2

Authentication and authorization are interchangeable.

Incorrect.

Authentication identifies.

Authorization grants permissions.

Trap 3

Encrypted passwords are secure.

Incorrect.

Passwords should be hashed with salt, not encrypted for storage.

Trap 4

HTTPS alone secures a web application.

Incorrect.

HTTPS protects data in transit but does not prevent application-layer vulnerabilities such as XSS or broken access control.

Trap 5

Developers are solely responsible for software security.

Incorrect.

Secure software requires collaboration among development, security, operations, architecture, governance, and management.

Manager's Decision Framework

Before approving an application for production, ask:

1. Have authentication and authorization been independently reviewed?

2. Is all user input validated on the server?

3. Are passwords properly hashed and salted?

4. Are secrets securely managed?

5. Are APIs adequately protected?

6. Has the application been reviewed against common security vulnerabilities?

7. Are logging and monitoring sufficient for incident detection and investigation?

Domain 8 Memory Sheet

Input Validation

• Validate everything

Output Encoding

• Prevent XSS

Authentication

• Who are you?

Authorization

• What can you do?

Session Management

• Protect user sessions

Secrets Management

• Never hardcode credentials

SQL Injection

• Parameterized queries

XSS

• Output encoding

CSRF

• CSRF tokens

Broken Access Control

• Server-side enforcement

OWASP Top 10

• Common application risks

CISSP Exam Tips

• Input validation and output encoding are two of the most effective defenses against common web application attacks.

• Passwords should be hashed with modern, adaptive algorithms and unique salts—not encrypted for storage.

• Authentication establishes identity; authorization determines permissions.

• Protect secrets throughout the software lifecycle, including source code repositories, CI/CD pipelines, and production environments.

• The CISSP exam focuses on governance and secure development practices, not writing code or memorizing programming languages.

Quick Knowledge Check

1. Why is server-side validation essential even when client-side validation is implemented?

2. What is the difference between authentication and authorization?

3. Why should passwords be hashed rather than encrypted for storage?

4. How does output encoding help prevent Cross-Site Scripting (XSS)?

5. Why should secrets never be stored in source code?

6. What protections should every secure REST API implement?

7. How does the Shared Responsibility Model influence cloud application security?

8. What is the purpose of secure session management?

9. Why is broken access control one of the most critical application security risks?

10. How does the OWASP Top 10 help organizations improve software security?

Key Takeaways

• Secure software development relies on layered defenses including input validation, output encoding, strong authentication, robust authorization, secure session management, and proper secrets handling.

• Application security is a governance responsibility as much as a technical one, requiring collaboration between development, security, operations, and management.

• OWASP Top 10 vulnerabilities provide a practical framework for understanding and mitigating the most common software security risks.

• Secure coding practices significantly reduce the likelihood of exploitable vulnerabilities reaching production.

• The CISSP manager's mindset emphasizes building secure development processes, enforcing security requirements, and reducing business risk through proactive software security rather than relying solely on technical fixes.

Why Software Security Testing Matters

No software is secure simply because it was developed following best practices.

Applications must be continuously verified to ensure they:

• Meet security requirements

• Resist attacks

• Protect sensitive data

• Comply with regulations

• Minimize business risk

Software Security Assurance

Security assurance provides confidence that software satisfies security objectives.

Objectives include:

• Verify secure implementation

• Identify vulnerabilities

• Validate security controls

• Reduce business risk

• Improve software quality

• Support regulatory compliance

Software Testing Lifecycle

Requirements
      ↓
Threat Modeling
      ↓
Secure Coding
      ↓
Code Review
      ↓
Security Testing
      ↓
Remediation
      ↓
Retesting
      ↓
Deployment
      ↓
Continuous Monitoring

Security testing is continuous, not a single event.

Verification vs Validation

Frequently tested.

Verification

Answers:

Examples

• Code review

• Static analysis

• Secure coding standards

Validation

Answers:

Examples

• Penetration testing

• User acceptance testing

• Business requirement verification

Code Reviews

One of the most effective security controls.

Objectives

• Detect vulnerabilities early

• Improve software quality

• Share knowledge

• Enforce coding standards

Manual Code Review

Performed by experienced developers or security engineers.

Advantages

• Finds logic flaws

• Identifies business logic errors

• Detects insecure design

Disadvantages

• Time consuming

• Requires expertise

Automated Code Review

Uses automated analysis tools.

Advantages

• Fast

• Repeatable

• Consistent

Limitations

• Cannot detect every logical flaw

• May produce false positives

Peer Review

Developers review each other's code before merging.

Benefits

• Higher quality

• Better maintainability

• Knowledge sharing

• Reduced defects

Security Testing Pyramid

Unit Tests
      ↓
Integration Tests
      ↓
System Tests
      ↓
Security Tests
      ↓
Acceptance Tests

Testing should become progressively broader.

Static Application Security Testing (SAST)

SAST analyzes source code, bytecode, or binaries without executing the application.

Characteristics

• White-box testing

• Early SDLC

• Detects coding flaws

• Developer friendly

Common findings

• SQL Injection

• Buffer Overflow

• Hardcoded secrets

• Weak cryptography

• Input validation issues

Advantages of SAST

✔ Early detection

✔ Lower remediation cost

✔ Automated

✔ Integrated into CI/CD

Limitations of SAST

• Cannot identify runtime issues

• May produce false positives

• Limited business context

Dynamic Application Security Testing (DAST)

DAST tests a running application.

Characteristics

• Black-box approach

• No source code required

• Detects runtime issues

Findings

• Authentication flaws

• Session management

• Misconfigurations

• Runtime vulnerabilities

Advantages of DAST

✔ Real-world testing

✔ Detects deployment issues

✔ No source code required

Limitations of DAST

• Requires running application

• Finds issues later

• Limited code visibility

Interactive Application Security Testing (IAST)

IAST combines:

SAST

DAST

It observes application behavior while code executes.

Advantages

• More accurate

• Better context

• Lower false positives

Runtime Application Self-Protection (RASP)

RASP protects applications while they are running.

Capabilities

• Runtime monitoring

• Detect attacks

• Block attacks

• Protect applications automatically

Software Composition Analysis (SCA)

Modern applications rely heavily on third-party components.

SCA identifies:

• Vulnerable libraries

• Open-source risks

• License issues

• Dependency vulnerabilities

Software Bill of Materials (SBOM)

An SBOM documents:

• Libraries

• Dependencies

• Frameworks

• Versions

• Vendors

Benefits

• Faster vulnerability response

• Better supply chain visibility

• Compliance support

Dependency Management

Third-party components should be:

• Trusted

• Updated

• Reviewed

• Monitored

Organizations should remove unused dependencies.

Fuzz Testing

Fuzzing sends unexpected or malformed input to applications.

Purpose

Identify:

• Crashes

• Memory corruption

• Buffer overflows

• Unexpected behavior

Unit Testing

Tests individual software components.

Objectives

• Validate functions

• Improve reliability

• Detect coding defects

Integration Testing

Tests communication between components.

Examples

• API integration

• Database interaction

• Authentication services

System Testing

Evaluates the complete application.

Focus

• Functionality

• Performance

• Security

• Reliability

User Acceptance Testing (UAT)

Business users validate that software satisfies operational requirements.

Security remains important during UAT.

Regression Testing

Ensures software changes do not introduce new defects.

Regression testing should follow:

• Bug fixes

• Security patches

• New features

• Configuration changes

Penetration Testing

Penetration testing validates exploitability.

Unlike SAST or DAST,

it simulates realistic attacks.

Objectives

• Validate vulnerabilities

• Assess business impact

• Verify security controls

Vulnerability Assessment vs Penetration Testing

Secure Build Process

Every build should be:

• Repeatable

• Automated

• Version controlled

• Verified

• Digitally signed

Build servers are high-value targets.

Build Integrity

Protect build environments through:

• MFA

• Least privilege

• Code signing

• Artifact verification

• Secure secrets management

Software Supply Chain Security

Supply chain attacks target:

• Build systems

• Third-party libraries

• Development tools

• Package repositories

• CI/CD pipelines

Recent attacks have demonstrated that trusted software can become malicious if the supply chain is compromised.

Code Signing

Code signing proves:

• Authenticity

• Integrity

• Publisher identity

Users can verify software has not been modified.

Digital Signatures

Digital signatures provide:

• Integrity

• Authentication

• Non-repudiation

They do not provide confidentiality.

Secure Release Management

Release processes should include:

• Security approval

• Automated testing

• Version control

• Rollback capability

• Documentation

• Deployment verification

Security Testing Best Practices

✔ Perform code reviews

✔ Automate SAST

✔ Perform DAST before release

✔ Review third-party libraries

✔ Maintain SBOM

✔ Protect build servers

✔ Digitally sign releases

✔ Validate fixes

✔ Continuously monitor production

✔ Continuously improve

Common CISSP Exam Traps

Trap 1

SAST replaces DAST.

Incorrect.

They complement each other.

Trap 2

Penetration testing should occur before code review.

Incorrect.

Security should begin earlier with secure coding and code reviews.

Trap 3

Open-source software is inherently insecure.

Incorrect.

Risk depends on governance, maintenance, and monitoring—not whether software is open source.

Trap 4

Digital signatures provide confidentiality.

Incorrect.

They provide integrity, authentication, and non-repudiation.

Trap 5

Software testing ends after deployment.

Incorrect.

Monitoring, patching, and continuous validation continue throughout the software lifecycle.

Manager's Decision Framework

Before approving software for production, ask:

1. Has the code undergone peer review?

2. Were SAST and DAST performed?

3. Have third-party libraries been evaluated?

4. Is an SBOM available?

5. Is the build process secure and repeatable?

6. Are releases digitally signed?

7. Has remediation been verified before deployment?

Domain 8 Memory Sheet

SAST

• Static

• White-box

• Early SDLC

DAST

• Dynamic

• Black-box

• Running application

IAST

• Hybrid testing

RASP

• Runtime protection

SCA

• Third-party libraries

SBOM

• Software inventory

Regression Testing

• Verify changes

Code Review

• Improve quality

Penetration Testing

• Validate exploitability

Code Signing

• Integrity and authenticity

CISSP Exam Tips

• No single testing method is sufficient. Mature organizations combine SAST, DAST, IAST, code reviews, penetration testing, and continuous monitoring.

• Software supply chain security is a growing CISSP focus. Protect build pipelines, verify dependencies, and maintain an accurate SBOM.

• Code reviews are among the most cost-effective ways to identify vulnerabilities early.

• Digital signatures verify integrity and authenticity—they do not encrypt data.

• The CISSP manager's mindset prioritizes governance, secure processes, and continuous assurance rather than individual testing tools.

Quick Knowledge Check

1. What is the primary difference between SAST and DAST?

2. Why are code reviews valuable even when automated testing is used?

3. What risks does Software Composition Analysis (SCA) help identify?

4. Why has the Software Bill of Materials (SBOM) become increasingly important?

5. How does fuzz testing uncover vulnerabilities?

6. What security benefits does code signing provide?

7. Why should build servers receive the same level of protection as production systems?

8. How does regression testing support secure software maintenance?

9. Why are digital signatures important in software distribution?

10. Why should software security testing continue after deployment?

Key Takeaways

• Software security testing is an ongoing assurance process that combines manual reviews, automated analysis, runtime testing, and continuous monitoring.

• SAST, DAST, IAST, RASP, and penetration testing each address different aspects of application security and are most effective when used together.

• Software supply chain security has become a critical concern, making dependency management, SCA, SBOMs, secure builds, and code signing essential components of a mature development program.

• Secure release management requires repeatable builds, verified artifacts, and strong governance over deployment pipelines.

• The CISSP manager's mindset focuses on building trustworthy development processes that reduce business risk through continuous verification, secure software governance, and lifecycle-wide assurance.

Why Operational Software Security Matters

Software security does not end after deployment.

New threats emerge daily:

• Zero-day vulnerabilities

• Supply chain attacks

• Misconfigurations

• Credential theft

• Vulnerable dependencies

• Cloud misconfigurations

• Insider threats

Security must continue throughout the application's operational life.

DevSecOps

DevSecOps integrates security into every phase of software delivery.

Instead of:

Development

↓

Testing

↓

Security Review

↓

Deployment

DevSecOps becomes

Plan
     ↓
Code
     ↓
Build
     ↓
Security Testing
     ↓
Deploy
     ↓
Monitor
     ↓
Improve

Security becomes everyone's responsibility.

DevOps vs DevSecOps

DevSecOps Objectives

• Shift security left

• Automate security

• Improve software quality

• Reduce vulnerabilities

• Accelerate secure releases

• Improve compliance

• Reduce operational risk

CI/CD Pipeline Security

Continuous Integration

↓

Continuous Testing

↓

Continuous Security Testing

↓

Continuous Deployment

↓

Continuous Monitoring

Every stage should include security controls.

Securing the CI/CD Pipeline

Protect:

• Source code

• Build servers

• Artifact repositories

• Deployment tools

• Secrets

• Signing certificates

• Cloud credentials

Pipeline compromise can compromise every released application.

Source Code Management

Repositories should enforce:

✔ MFA

✔ Branch protection

✔ Pull request reviews

✔ Signed commits

✔ Least privilege

✔ Audit logging

Examples

• GitHub

• GitLab

• Azure DevOps

• Bitbucket

Version Control

Version control provides:

• Traceability

• Accountability

• Rollback capability

• Collaboration

• Audit history

Every production release should map to a specific version.

Infrastructure as Code (IaC)

Infrastructure is defined using code.

Examples

• Terraform

• AWS CloudFormation

• Azure Bicep

• Pulumi

Advantages

• Repeatability

• Consistency

• Automation

Security must review infrastructure code just like application code.

IaC Security

Review for:

• Hardcoded secrets

• Public cloud resources

• Excessive permissions

• Misconfigured storage

• Insecure networking

• Open security groups

Container Security

Containers package applications and dependencies.

Benefits

• Portability

• Consistency

• Scalability

Security considerations

• Minimal base images

• Signed images

• Vulnerability scanning

• Least privilege

• Runtime monitoring

Kubernetes Security

Kubernetes introduces additional risks.

Secure:

• API Server

• RBAC

• Secrets

• Pods

• Nodes

• Admission controllers

• Network policies

Secure Deployment

Before deployment verify:

• Security testing completed

• Vulnerabilities remediated

• Configuration approved

• Secrets protected

• Rollback available

• Monitoring enabled

Release Approval

Production releases should require:

Developer

↓

Code Reviewer

↓

Security Review

↓

Operations Approval

↓

Production Deployment

No individual should deploy unreviewed code directly into production.

Configuration Management

Secure software depends on secure configuration.

Maintain:

• Approved baselines

• Secure defaults

• Version tracking

• Change documentation

• Configuration audits

Configuration Drift

Configuration drift occurs when deployed systems differ from approved baselines.

Causes include

• Manual changes

• Emergency fixes

• Unauthorized modifications

• Patch inconsistencies

Continuous monitoring detects drift early.

Change Management

All software changes should follow:

Request
      ↓
Risk Review
      ↓
Approval
      ↓
Testing
      ↓
Deployment
      ↓
Validation
      ↓
Documentation

Emergency changes require retrospective documentation.

Patch Management

Applications require continuous updates.

Patch priorities depend on:

• Business impact

• Active exploitation

• Criticality

• Internet exposure

• Regulatory requirements

Business risk—not CVSS alone—determines priority.

Software Supply Chain Security

Modern applications depend heavily on third-party software.

Potential risks

• Compromised libraries

• Malicious packages

• Build server compromise

• Dependency confusion

• Package typosquatting

• Malicious updates

Third-Party Components

Organizations should:

• Approve vendors

• Monitor vulnerabilities

• Maintain SBOM

• Remove unused libraries

• Review licenses

• Patch regularly

Software Bill of Materials (SBOM)

SBOM documents

• Components

• Versions

• Vendors

• Dependencies

• Licenses

Benefits

• Faster incident response

• Compliance

• Vulnerability management

• Supply chain transparency

Dependency Management

Third-party libraries should be

• Trusted

• Current

• Supported

• Continuously monitored

Avoid unnecessary dependencies.

Secure Secrets Management

Protect:

• API Keys

• Database Credentials

• Tokens

• Certificates

• Cloud Secrets

Never:

• Hardcode credentials

• Store secrets in repositories

• Share secrets through email

Use enterprise secret vaults.

Code Signing

Every production release should be digitally signed.

Benefits

• Integrity

• Authenticity

• Trust

Unsigned software increases supply chain risk.

Artifact Management

Build artifacts should be:

• Immutable

• Versioned

• Signed

• Verified

• Stored securely

Secure Deployment Validation

After deployment verify:

• Services running

• Authentication working

• Logging enabled

• Monitoring active

• Security controls functioning

• No unexpected changes

Deployment success requires both functional and security validation.

Application Monitoring

Monitor

• Authentication failures

• Privileged actions

• API activity

• Configuration changes

• Performance

• Security alerts

• Availability

Monitoring supports rapid incident detection.

Runtime Security

Applications should monitor

• Unauthorized changes

• Memory abuse

• Privilege escalation

• API abuse

• Malware

• Unexpected behavior

Runtime protection complements secure development.

Operational Metrics

Examples

Deployment Success Rate

↓

Change Failure Rate

↓

Patch Compliance

↓

Application Availability

↓

Mean Time to Recover (MTTR)

↓

Vulnerability Remediation Time

↓

Release Frequency

↓

Security Defect Density

Executives monitor trends rather than individual events.

Cloud-Native Security

Protect:

• Containers

• Serverless Functions

• Kubernetes

• APIs

• IAM

• Storage

• Secrets

Cloud applications require continuous monitoring.

Secure Retirement

Software eventually reaches end-of-life.

Retirement activities include:

• Archive data

• Remove credentials

• Destroy secrets

• Update inventories

• Remove dependencies

• Revoke certificates

• Document retirement

Failure to retire software properly creates unnecessary risk.

Secure Software Lifecycle

Requirements
      ↓
Design
      ↓
Development
      ↓
Testing
      ↓
Deployment
      ↓
Operations
      ↓
Monitoring
      ↓
Maintenance
      ↓
Retirement

Security exists at every stage.

Secure Software Best Practices

✔ Automate security testing

✔ Protect CI/CD pipelines

✔ Digitally sign releases

✔ Monitor applications continuously

✔ Review dependencies

✔ Protect secrets

✔ Secure containers

✔ Validate deployments

✔ Continuously patch

✔ Improve processes

Common CISSP Exam Traps

Trap 1

DevSecOps slows software delivery.

Incorrect.

Proper automation enables secure and rapid releases.

Trap 2

Security ends after deployment.

Incorrect.

Monitoring and maintenance continue throughout the software lifecycle.

Trap 3

SBOMs are only for compliance.

Incorrect.

They also improve vulnerability response and supply chain visibility.

Trap 4

Containers are secure by default.

Incorrect.

They require secure images, least privilege, vulnerability scanning, and runtime monitoring.

Trap 5

Version control is only for developers.

Incorrect.

It provides accountability, auditability, rollback capability, and governance.

Trap 6

Infrastructure as Code eliminates security risks.

Incorrect.

IaC must itself be reviewed, tested, and secured like application code.

Manager's Decision Framework

Before approving a production deployment, ask:

1. Has security testing been completed?

2. Are all critical vulnerabilities remediated or formally accepted?

3. Is the CI/CD pipeline protected?

4. Have third-party dependencies been reviewed?

5. Is an SBOM available and current?

6. Are secrets securely managed?

7. Is monitoring in place after deployment?

Domain 8 Memory Sheet

DevSecOps

• Security everywhere

CI/CD

• Automate securely

IaC

• Infrastructure as code

SBOM

• Software inventory

SCA

• Component analysis

Containers

• Secure images

Version Control

• Traceability

Code Signing

• Integrity

Secrets Management

• Never hardcode

Runtime Monitoring

• Continuous protection

CISSP Exam Tips

• DevSecOps integrates security into every phase of software delivery, making security a shared organizational responsibility.

• Software supply chain security is a major modern focus. Understand SBOMs, dependency management, code signing, and secure build pipelines.

• Infrastructure as Code, containers, and cloud-native technologies require the same governance and security review as traditional software.

• Protect the CI/CD pipeline as rigorously as production systems, since compromise can affect every software release.

• The CISSP manager's mindset prioritizes secure processes, governance, and continuous operational assurance over specific development tools.

Quick Knowledge Check

1. How does DevSecOps improve software security compared to traditional DevOps?

2. Why should CI/CD pipelines be treated as high-value assets?

3. What security benefits does an SBOM provide?

4. Why must Infrastructure as Code undergo security review?

5. What controls are essential for securing containers and Kubernetes environments?

6. Why is code signing important for software distribution?

7. How does version control support software governance and auditing?

8. What risks arise from poorly managed third-party dependencies?

9. Why is continuous application monitoring necessary after deployment?

10. What activities should be completed before securely retiring software?

Key Takeaways

• Software security extends well beyond development, requiring secure deployment, continuous monitoring, controlled change management, and disciplined retirement processes.

• DevSecOps, CI/CD security, Infrastructure as Code, containers, and software supply chain security are central to modern software governance and frequently tested at the CISSP level.

• Software supply chain protection depends on secure build pipelines, trusted dependencies, SBOMs, artifact integrity, code signing, and strong secrets management.

• Operational excellence requires continuous monitoring, secure configuration management, vulnerability remediation, and measurable security metrics throughout the application lifecycle.

• The CISSP manager's mindset emphasizes governance, resilience, risk reduction, and continuous improvement to ensure software remains secure from initial design through retirement.

Domain 8 in One Sentence

Domain 8 Master Framework

Business Requirements
          ↓
Security Requirements
          ↓
Threat Modeling
          ↓
Secure Design
          ↓
Secure Development
          ↓
Security Testing
          ↓
Secure Deployment
          ↓
Continuous Monitoring
          ↓
Maintenance
          ↓
Secure Retirement

Everything in Domain 8 supports this lifecycle.

Top 100 Domain 8 CISSP Facts

Secure Development

✓ Security begins during requirements.

✓ SSDLC extends SDLC.

✓ Shift Left reduces cost.

✓ Secure by Design is proactive.

✓ Secure by Default minimizes exposure.

✓ Defense in Depth applies to software.

✓ Least Privilege applies to applications.

✓ Threat modeling occurs before coding.

✓ Security is everyone's responsibility.

✓ DevSecOps integrates Security into DevOps.

Authentication

Authentication proves identity.

Authorization grants permissions.

MFA greatly reduces account compromise.

Passwords should be hashed—not encrypted—for storage.

Application Security

Validate all input.

Encode all output.

Fail securely.

Never trust user input.

Protect secrets.

Log security events.

Encrypt sensitive information.

OWASP

Understand:

• Broken Access Control

• Injection

• Security Misconfiguration

• Cryptographic Failures

• Vulnerable Components

These concepts appear frequently in CISSP questions.

Security Testing

Code Reviews

↓

SAST

↓

DAST

↓

IAST

↓

Penetration Testing

↓

Continuous Monitoring

Each provides different assurance.

SAST

Static

White-box

Early SDLC

DAST

Dynamic

Black-box

Running application

IAST

Combines static and runtime context.

RASP

Runtime protection.

SCA

Reviews third-party libraries.

S

BOM

Inventory of software components.

DevSecOps

Security integrated into:

Plan

↓

Code

↓

Build

↓

Test

↓

Deploy

↓

Operate

↓

Monitor

CI/CD

Automated delivery.

Security must exist throughout the pipeline.

Containers

Require:

• Secure images

• Least privilege

• Runtime monitoring

• Image scanning

IaC

Infrastructure requires security reviews just like application code.

Code Signing

Provides:

• Integrity

• Authenticity

• Trust

Digital Signatures

Provide:

• Integrity

• Authentication

• Non-repudiation

Not confidentiality.

Supply Chain Security

Protect:

• Build servers

• Dependencies

• Artifact repositories

• Package managers

• Deployment pipelines

Secure Retirement

Remove:

• Credentials

• Secrets

• Certificates

• Access

• Dependencies

Retire software securely.

High-Value Comparison Tables

SDLC vs SSDLC

Waterfall vs Agile

DevOps vs DevSecOps

Authentication vs Authorization

SAST vs DAST

SAST vs IAST

DAST vs Penetration Testing

Code Review vs Penetration Testing

SCA vs SBOM

Encryption vs Hashing

Code Signing vs Encryption

Secure by Design vs Secure by Default

Client Validation vs Server Validation

Functional vs Non-Functional Requirements

Open Source vs Proprietary Software

Security depends on governance—not licensing.

CISSP Manager Decision Trees

New Application Project

Security Requirements Defined?

↓

Yes

↓

Threat Modeling

↓

Secure Design

↓

Secure Development

↓

Testing

↓

Deployment

↓

Monitoring

Vulnerability Found

Critical?

↓

Yes

↓

Immediate Remediation

↓

Retest

↓

Deploy

No

↓

Risk Assessment

↓

Prioritize

↓

Schedule Fix

Third-Party Library

Trusted?

↓

Yes

↓

Review

↓

Scan

↓

Monitor

↓

Deploy

No

↓

Reject

↓

Alternative Component

Deployment

Security Testing Complete?

↓

Yes

↓

Approve Release

↓

Monitor Production

No

↓

Delay Release

Top 50 CISSP Exam Traps

Trap 1

Security starts during testing.

Incorrect.

Security starts during requirements.

Trap 2

Authentication equals authorization.

Incorrect.

Authentication proves identity.

Authorization grants permissions.

Trap 3

SAST replaces DAST.

Incorrect.

They complement each other.

Trap 4

DevOps automatically includes security.

Incorrect.

DevSecOps integrates security.

Trap 5

HTTPS prevents application attacks.

Incorrect.

It protects communications only.

Trap 6

Client validation is enough.

Incorrect.

Server validation is mandatory.

Trap 7

RAID protects software.

Incorrect.

RAID improves availability—not software security.

Trap 8

Containers are secure by default.

Incorrect.

They require hardening and monitoring.

Trap 9

Digital signatures encrypt software.

Incorrect.

They verify integrity and authenticity.

Trap 10

Software security ends after deployment.

Incorrect.

Monitoring continues throughout operations.

Trap 11–50

Reinforce these recurring principles:

• Security is continuous.

• Governance is more important than tools.

• Business risk drives decisions.

• Secure processes outperform isolated controls.

• Threat modeling reduces downstream costs.

• Protect CI/CD pipelines.

• Validate fixes before release.

• Monitor production continuously.

• Review third-party software regularly.

• Retire software securely.

CISSP Memory Palace

Imagine walking through a secure software factory:

Planning Room → Requirements

Architecture Office → Threat Modeling

Design Studio → Secure by Design

Development Lab → Secure Coding

Code Review Room → Peer Review

Testing Center → SAST / DAST / IAST

Build Pipeline → CI/CD

Signing Station → Code Signing

Deployment Gateway → Production Release

Operations Center → Monitoring

Maintenance Workshop → Patch Management

Retirement Archive → Secure Decommissioning

This journey mirrors the complete Secure Software Development Lifecycle.

Manager's Mindset

Before approving any software release, ask:

• Does it reduce business risk?

• Are security requirements satisfied?

• Has threat modeling been completed?

• Has the software been independently tested?

• Are dependencies trusted?

• Is the deployment process controlled?

• Is production monitoring ready?

• Can the software be maintained securely?

Always think from the perspective of protecting the organization—not simply shipping features.

30 Rapid Review Questions

1

Purpose of SSDLC?

Answer

Integrate security throughout software development.

2

What is Shift Left?

Answer

Move security earlier in development.

3

Difference between SDLC and SSDLC?

Answer

SSDLC integrates security into every phase.

4

Purpose of SAST?

Answer

Analyze source code for vulnerabilities.

5

Purpose of DAST?

Answer

Test a running application.

6

Purpose of IAST?

Answer

Combine runtime analysis with application instrumentation.

7

Purpose of RASP?

Answer

Protect applications during execution.

8

Purpose of SCA?

Answer

Identify vulnerable third-party components.

9

Purpose of SBOM?

Answer

Inventory software components and dependencies.

10

Purpose of Code Signing?

Answer

Verify integrity and authenticity.

11–30 (Rapid Recall)

• Why perform threat modeling?

• What is Secure by Default?

• Why is least privilege important for applications?

• What protects against SQL Injection?

• How does output encoding prevent XSS?

• Why should passwords be hashed?

• What secures CI/CD pipelines?

• Why review Infrastructure as Code?

• What is the Shared Responsibility Model?

• Why are secrets vaults important?

• How do containers improve portability?

• What is dependency confusion?

• Why monitor software after deployment?

• Why validate security patches?

• What activities occur during software retirement?

• Why are peer reviews valuable?

• What distinguishes code review from penetration testing?

• Why are digital signatures important?

• What is the role of DevSecOps?

• What is the ultimate goal of Domain 8?

10 Executive Scenario Questions

Scenario 1

A project team wants to postpone security testing until after deployment to meet a release deadline.

Best action?

Delay deployment until critical security testing is completed. Accepting known, unmitigated risk without formal approval exposes the organization unnecessarily.

Scenario 2

A developer stores API keys in a public Git repository.

Best response?

Rotate the exposed credentials immediately, remove the secrets from the repository history where feasible, investigate potential misuse, and implement centralized secrets management.

Scenario 3

A third-party library receives a critical vulnerability advisory.

Best action?

Assess business impact, identify affected applications through the SBOM, prioritize remediation, test the update, and deploy according to change management procedures.

Scenario 4

A build server is compromised.

Primary concern?

The integrity of every software artifact produced by that build environment may be in question.

Scenario 5

Executives request software security metrics.

Provide

• Vulnerability trends

• Remediation time

• Release quality

• Security testing coverage

• Critical dependency exposure

• Patch compliance

Scenario 6

Developers want to disable code reviews to accelerate delivery.

Best response?

Maintain code reviews while improving automation elsewhere. Code reviews are a key preventive control for quality and security.

Scenario 7

A container image contains unnecessary packages and services.

Best action?

Use a minimal, hardened base image and remove unused components to reduce the attack surface.

Scenario 8

Security testing reveals a medium-severity vulnerability immediately before release.

Best action?

Evaluate business risk, exploitability, compensating controls, and organizational risk tolerance before deciding to remediate immediately or formally accept the risk.

Scenario 9

A CI/CD pipeline lacks multifactor authentication.

Primary risk?

Unauthorized access could compromise the software build and release process.

Scenario 10

An application reaches end-of-life.

Best action?

Retire it securely by removing access, revoking certificates, destroying secrets, archiving required data, updating inventories, and documenting the retirement process.

Last Hour Before the CISSP Exam

Remember these key associations:

• SSDLC → Secure development lifecycle

• Shift Left → Security early

• Secure by Design → Security built in

• Secure by Default → Secure configuration

• Threat Modeling → Identify risks before coding

• SAST → Static code analysis

• DAST → Running application testing

• IAST → Combined analysis

• RASP → Runtime protection

• SCA → Dependency analysis

• SBOM → Software inventory

• DevSecOps → Security everywhere

• CI/CD → Secure automation

• Code Signing → Integrity

• Digital Signature → Integrity + Authentication + Non-repudiation

• Hashing → Password storage

• Encryption → Data confidentiality

• Secrets Management → Never hardcode credentials

• Secure Retirement → Remove access and secrets

Domain 8 Success Formula

Define Security Requirements
          ↓
Threat Model
          ↓
Design Securely
          ↓
Develop Securely
          ↓
Verify Security
          ↓
Deploy Securely
          ↓
Monitor Continuously
          ↓
Maintain Securely
          ↓
Retire Securely

Final Domain 8 Takeaways

• Software security is a lifecycle discipline, not a single development activity. Security must be embedded from requirements through retirement.

• Governance, secure processes, and continuous assurance are more important to the CISSP than knowledge of specific programming languages or frameworks.

• Modern software security depends on DevSecOps, secure CI/CD pipelines, software supply chain protection, dependency management, SBOMs, and continuous monitoring.

• Risk-based decision making should guide software releases, vulnerability remediation, and operational maintenance.

• Think like a CISSP leader: your responsibility is to ensure software is developed, deployed, operated, and retired securely while supporting business objectives and reducing organizational risk.

Domain 8 Knowledge Check – CISSP-Style Practice Questions

Question 1

A software development team wants to postpone security testing until after the application has been deployed to production because the release deadline is approaching.

What is the BEST recommendation from a CISSP perspective?

A. Deploy immediately and rely on penetration testing after release

B. Delay the release until critical security testing has been completed

C. Disable non-essential security controls temporarily

D. Accept all identified vulnerabilities because security can be improved later

Correct Answer: B

Explanation

Security should be integrated throughout the Secure Software Development Life Cycle (SSDLC). Releasing software without completing critical security testing increases business risk and may expose the organization to avoidable vulnerabilities.

• A is incorrect because penetration testing complements—not replaces—pre-release security testing.

• C weakens security controls without justification.

• D ignores risk management. Risks may only be accepted after formal evaluation and management approval.

Question 2

An organization wants to identify vulnerable third-party libraries used by its applications and maintain an inventory of all software dependencies.

Which combination provides the BEST solution?

A. SAST and DAST

B. Software Composition Analysis (SCA) and a Software Bill of Materials (SBOM)

C. Code Review and Penetration Testing

D. Runtime Application Self-Protection (RASP) and Fuzz Testing

Correct Answer: B

Explanation

Software Composition Analysis (SCA) identifies vulnerable open-source and third-party components, while an SBOM provides a comprehensive inventory of software components and dependencies.

• A analyzes application security but not dependency inventories.

• C focuses on code quality and exploitability.

• D addresses runtime protection and robustness, not dependency management.

Question 3

Which statement BEST describes the primary difference between DevOps and DevSecOps?

A. DevSecOps replaces developers with security engineers.

B. DevOps focuses only on cloud computing.

C. DevSecOps integrates security into every phase of the software delivery pipeline.

D. DevSecOps eliminates the need for security testing.

Correct Answer: C

Explanation

DevSecOps extends DevOps by embedding security throughout planning, development, testing, deployment, and operations.

• A is incorrect because security is a shared responsibility.

• B is unrelated.

• D is incorrect because DevSecOps increases—not eliminates—security testing.

Question 4

A security architect recommends digitally signing every production software release.

What security objective is PRIMARILY achieved?

A. Confidentiality

B. Availability

C. Integrity and authenticity

D. Access control

Correct Answer: C

Explanation

Digital signatures verify that software has not been altered and confirm the identity of the publisher.

They provide:

• Integrity

• Authentication

• Non-repudiation

They do not provide confidentiality.

• A is incorrect because encryption provides confidentiality.

• B relates to system uptime.

• D concerns permissions rather than software authenticity.

Question 5

During an application security review, developers state that client-side validation is sufficient because users cannot submit invalid data through the application's forms.

What is the BEST response?

A. Client-side validation is adequate for modern web applications.

B. Client-side validation should be removed entirely.

C. Server-side validation is still required because client-side controls can be bypassed.

D. Client-side validation should be replaced by encryption.

Correct Answer: C

Explanation

Client-side validation improves usability but provides little security because attackers can bypass browser-based controls.

Server-side validation is mandatory to ensure all incoming data is properly validated before processing.

• A is incorrect because client-side validation alone is insufficient.

• B is incorrect because client-side validation still improves user experience.

• D confuses validation with encryption.

Related Articles (Internal Linking)

To strengthen SEO and user engagement, link this guide to:

• Secure Software Development Lifecycle (SSDLC)

• DevSecOps Explained

• Secure Coding Best Practices

• OWASP Top 10 Explained

• Threat Modeling

• Authentication vs Authorization

• Input Validation

• SQL Injection

• Cross-Site Scripting (XSS)

• Cross-Site Request Forgery (CSRF)

• Software Composition Analysis (SCA)

• Software Bill of Materials (SBOM)

• CI/CD Pipeline Security

• Container Security

• Kubernetes Security

• Infrastructure as Code (IaC)

• Secrets Management

• Secure Code Review

• SAST vs DAST vs IAST

• Software Supply Chain Security