Topics in this domain
- The Security Program: Charter, Scope and Objectives
- Security Team Structure, Roles and Staffing
- Working with Legal, HR, IT, Audit and the Business
- Program Implementation: From Plan to Operating Controls
- Information Asset Identification and Valuation
- Data Classification: Owners, Custodians and Users
- Data Lifecycle: Retention, Archiving and Secure Disposal
- Enterprise Architecture for Security Managers
- Information Security Architecture: Principles and SABSA
- Defence in Depth and Zero Trust
- Cloud Security and Shared Responsibility
- Control Frameworks: NIST SP 800-53, CIS Controls and ISO 27002
- Security Policy Development and Lifecycle
- Security Standards and Baseline Requirements
- Procedures, Guidelines and Acceptable Use
- Policy Enforcement, Exceptions and Review
- Designing Security Metrics: KPIs, KRIs and KCIs
- Collecting, Analysing and Reporting Metrics
- Security Maturity Models and Program Assessment
- Control Types and Categories
- Control Design and Selection Based on Risk and Cost
- Control Testing: Design vs Operating Effectiveness
- Identity and Access Management
- Network and Endpoint Security Controls
- Application Security and the Secure SDLC
- Configuration, Change and Patch Management
- Cryptography for Security Managers
- Security Testing: Scanning, Pen Testing and Tracking Remediation
- Security Awareness Program Design
- Role-Based Security Training
- Phishing Simulations and Social Engineering Defences
- Third-Party Risk Management and Due Diligence
- Vendor Contracts, SLAs and Right to Audit
- Fourth-Party and Supply Chain Risk
- Outsourcing and Managed Security Services
- Security Stakeholder Communication
- Executive Dashboards and Board Reporting
- Continuous Improvement of the Security Program
Application Security and the Secure SDLC
Built in, not bolted on
Most breaches of web applications exploit flaws that could have been prevented during design or coding. The security manager’s role is to make the secure way the normal way of building and buying software, through requirements, tools, training and release gates. This is part of the CISM task to integrate information security requirements into organisational processes.
The secure SDLC
| Stage | Security activities |
|---|---|
| Requirements | Security and privacy requirements; application risk rating |
| Design | Threat modelling; standard secure patterns |
| Build | Secure coding standards; peer code review; static analysis (SAST); dependency scanning |
| Test | Dynamic testing (DAST); penetration testing for high-risk applications |
| Release and run | Security sign-off; web application firewall; monitoring; patching |
Fixing a flaw in design costs a fraction of fixing it after release.
Shift left in DevSecOps
In DevOps, code moves to production many times a day. DevSecOps automates security checks in the delivery pipeline, so every change is scanned without slowing teams down. “Shift left” means adding checks earlier; it doesn’t mean dropping the later ones.
The software supply chain
- A software bill of materials (SBOM) lists every component in an application.
- Dependency scanning finds known vulnerabilities in open-source libraries.
- Trusted sources: approved repositories and signed packages.
- Purchased software: security requirements in contracts and evidence of the vendor’s testing.
Example. A critical vulnerability is announced in a widely used logging library. With an SBOM for each application, the security team identifies the 14 affected systems in an hour. Without one, a peer company takes three weeks.
Program-level controls
- a secure coding standard and developer training
- security requirements built into project templates
- automated security tests that can block releases
- risk-based penetration testing of high-risk applications
- metrics: open critical flaws, time to fix, scanning coverage
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| When to address security in development | From requirements onward |
| Most cost-effective time to fix a flaw | Design |
| Testing source code for flaws | Static analysis (SAST) |
| Inventory of software components | A software bill of materials (SBOM) |
| Role of a web application firewall | A compensating layer, not a replacement for secure code |
In short
- Security is integrated into each stage of the software development life cycle (SDLC), from requirements to operation.
- Fixing a flaw in design costs a fraction of fixing it after release.
- Key practices: security requirements, threat modelling, secure coding standards, code review, SAST, DAST, dependency scanning and penetration testing.
- In DevOps, security checks are automated in the pipeline (DevSecOps), and 'shift left' adds them earlier without removing later ones.
- Third-party and open-source components need inventory (SBOM) and vulnerability tracking.
- Purchased software also needs security requirements in contracts and testing before use.
Exam traps
- A web application firewall is a compensating layer, not a substitute for secure code.
- Shift left means testing earlier, not skipping testing later.
- Developers shouldn't approve and deploy their own code to production without review.
- Ignoring open-source dependencies leaves known vulnerabilities in production.
Slides
Click the slide and use the arrow keys. F toggles full screen.
The secure SDLC
Shift left in DevSecOps
1 / 9