8.1 Security in the SDLC

Key Takeaways

CISSP 8.1 is: Understand and integrate security in the Software Development Life Cycle.

The current ISC2 outline explicitly includes development methodologies, maturity models, operation and maintenance, change management and Integrated Product Teams.

The central principle is: security should be integrated throughout software development.

Security should influence requirements, design, development, testing, deployment, operation and change.

Security should not first appear immediately before production.

Secure development begins with understanding the protection needs of the business and translating those needs into security requirements.

Security requirements may address authentication, authorization, confidentiality, logging, privacy, resilience and other required behaviours.

Functional requirements describe what software should do.

Security requirements help describe the conditions under which it should do those things safely.

Secure design considers threats before implementation.

Threat modeling, trust boundaries, least privilege, secure defaults and attack-surface analysis can therefore occur before significant code exists.

Fix architecture before architecture becomes thousands of lines of code.

Shift left means performing security activities earlier in development.

Earlier identification of security weaknesses can reduce rework and technical debt.

Shift left ≠ security only on the left.

Production security, monitoring, vulnerability management and incident response remain necessary.

Waterfall develops software through relatively distinct sequential phases.

Security can and should be integrated into requirements, design, development, testing, deployment and maintenance within Waterfall.

Waterfall ≠ security only at final testing.

Agile uses iterative and incremental development.

Security can be incorporated into Agile backlogs, user stories, acceptance criteria and each development iteration.

Agile does not mean no planning, no documentation or no architecture.

DevOps brings development and operations closer together.

It emphasises shared responsibility, automation, rapid delivery and operational feedback.

DevSecOps explicitly integrates security within that delivery approach.

DevOps = Development + Operations. DevSecOps = Development + Security + Operations.

DevSecOps should not create another security silo.

Security becomes part of the same workflow used to develop, test, deploy and operate software.

Automation can make security checks repeatable and scalable.

But: automation ≠ guaranteed security.

An insecure automated process simply produces insecure outcomes more consistently and potentially more quickly.

Automated controls also require appropriate tuning.

Excessive false positives can cause developers to distrust or bypass security controls.

SAFe applies Agile concepts across larger coordinated development organisations.

The CISSP principle remains unchanged: security must remain integrated when Agile is scaled.

Maturity models help organisations assess and improve the consistency and capability of their processes.

The classic Capability Maturity Model progresses through five levels:

Initial → Repeatable → Defined → Managed → Optimizing.

Initial processes are relatively ad hoc and unpredictable.

Repeatable processes establish basic repeatability.

Defined processes use organisation-wide standards.

Managed processes are measured and controlled.

Optimizing organisations focus on continuous improvement.

Modern CMMI evolved from this maturity-model family and uses updated terminology.

CISSP explicitly includes CMM as the example in objective 8.1, so understanding the maturity concept is more important than treating every maturity model as identical.

OWASP SAMM focuses specifically on software security and assurance.

SAMM contains five high-level business functions:

Governance → Design → Implementation → Verification → Operations.

SAMM can help an organisation understand its current software-security maturity, define a target and create an improvement roadmap.

CMM = broad development-process maturity. SAMM = software-security maturity.

NIST's Secure Software Development Framework provides another useful modern model for secure development.

The current final SSDF 1.1 contains four groups:

Prepare the Organization → Protect the Software → Produce Well-Secured Software → Respond to Vulnerabilities.

The SSDF can be integrated into different SDLC methodologies rather than requiring one particular development model.

Operation and maintenance are explicitly included in CISSP 8.1.

A software release is therefore not the end of security responsibility.

Production software must continue to be monitored, patched, maintained and updated.

Dependencies, certificates, credentials, configurations and operating environments also change over time.

Secure at release ≠ secure forever.

Operational incidents should feed information back into development.

If an incident exposes a recurring development weakness, the mature response is not merely to repair one application.

The organisation should consider how the development process can prevent recurrence.

Change management is also explicitly included in objective 8.1.

Software changes should be evaluated for security impact.

A small functional change can create a large security impact.

Controlled change normally includes assessment, authorisation, testing, deployment, monitoring and traceability.

Emergency changes may use an expedited process.

Emergency change ≠ uncontrolled change.

Appropriate documentation and post-implementation review may still be necessary.

Integrated Product Teams bring multiple disciplines together.

Product owners, developers, security specialists, architects, testers, operations personnel and other relevant stakeholders can participate before decisions become expensive to change.

Security should participate in building the product rather than only judging the finished product.

Security champions can help integrate security knowledge into development teams.

They do not automatically replace specialist security teams.

Verification and validation are related but different.

Verification asks: did we build it right?

Validation asks: did we build the right thing?

Correctly implementing a weak security requirement does not make the resulting security strong.

Security requirements should therefore themselves be appropriate to business risk.

Security activities should be risk-based.

An Internet banking service and a low-risk internal utility do not necessarily require identical levels of assurance.

Requirements should be traceable where appropriate from risk through design, implementation and testing.

This helps demonstrate that identified security needs were actually addressed.

Repeated vulnerabilities may indicate a development-process problem.

Mature organisations therefore examine root causes.

Fix the vulnerability. Then ask why the development process allowed it.

Repeatedly postponing necessary security work can accumulate security debt.

Security and development speed are not necessarily opposing goals.

Earlier security feedback can reduce late rework and unexpected release delays.

The current final NIST SSDF remains version 1.1.

NIST has published version 1.2 as a draft, so it should not currently be described as the final SSDF.

The central CISSP principle for 8.1 is:

security is not one stage of software development. Security is a requirement and engineering responsibility that should follow the software from its earliest business need through design, implementation, verification, deployment, operation, change and continuous improvement.