Software Development Security Reference Guide
CISSP Domain 8 · 5 topics · Concepts, real-world examples, and controls
Security in the SDLC is not a phase — it is a discipline that runs through every phase. The cost of finding and fixing a vulnerability increases by an order of magnitude at each successive stage: a design flaw caught in requirements costs hours to fix; the same flaw found post-deployment costs months and may require a full re-architecture. Integrating security into the SDLC is fundamentally an economic decision, not just a risk management one.
Security activities by SDLC phase
Select a phase to see its specific security activities and what happens when they are skipped.
Requirements
Security requirements must be identified alongside functional requirements — before any design decisions are made. Who are the users? What data will the system process? What regulations apply? What are the threat actors and their capabilities? What are the CIA priorities? Unanswered security requirements at this phase propagate as design constraints that become increasingly expensive to address as development progresses. Security requirements should be specific, measurable, and testable — “the system must be secure” is not a requirement.
🌐 Real-world example
Healthcare.gov (2013): the security requirements for the federal health insurance marketplace were incomplete at the requirements phase — HIPAA applicability was identified late, privacy requirements were underspecified, and security testing was not given sufficient schedule allocation. The result was a launch with significant security vulnerabilities, an emergency post-launch security sprint, and congressional testimony about inadequate security planning. The MITRE Corporation’s post-launch assessment found that security requirements had not been integrated into the acquisition requirements for vendors — meaning contracted developers had no contractual obligation to meet specific security standards.
Development methodologies and security integration
Select a methodology to see how security integrates into it.
Waterfall
Sequential phases, formal gates
Agile
Iterative sprints, continuous delivery
DevOps
Dev + Ops culture and toolchain
DevSecOps
Security shift-left into DevOps
SAFe
Scaled Agile for large enterprises
Waterfall
Sequential, phase-gated methodology: Requirements → Design → Development → Testing → Deployment → Maintenance. Each phase must be completed before the next begins. Security integration is straightforward: define security gates at each phase transition. Security requirements are captured in Phase 1; security architecture reviewed in Phase 2; secure code review in Phase 3; security testing in Phase 4. The challenge: late discovery of security issues requires returning to earlier phases — expensive in a sequential model.
Security advantages and risks
Advantages: clear security gates, formal documentation of security requirements, defined testing phase. Risks: security findings in Phase 4 testing require going back to Phase 2 (design) — the cost of late discovery is high. Security cannot be “caught up” at the end in a Waterfall model; it must be built in from Phase 1.
Real-world example
The Space Shuttle software development program used a modified Waterfall model with extremely rigorous formal verification and security/safety gates at each phase transition. The result was software with a defect rate of approximately 0.1 defects per thousand lines of code — compared to the industry average of 1–5 defects per thousand lines. The cost was extremely high development time and expense. For safety-critical and high-security systems (aviation, medical devices, nuclear), the formal Waterfall model’s disciplined gate reviews remain the appropriate methodology.
Agile
Iterative development in short sprints (1–4 weeks), with working software delivered at the end of each sprint. Security must be integrated into the sprint cycle rather than bolted on at the end: security user stories (as a user, I need my session to expire after 30 minutes of inactivity), security acceptance criteria for each story, and security reviews as part of the “definition of done.” Threat modeling should be conducted at the start of each epic or significant new feature.
Security integration points
Security backlog items treated as first-class backlog items — not a separate security sprint. SAST integrated into the IDE and CI pipeline. Security acceptance criteria written at the same time as functional acceptance criteria. Regular security-focused sprint retrospectives. Security champion embedded in each Agile team to provide in-sprint security expertise.
Real-world example
Etsy’s security team pioneered the security champion model to scale security into an Agile engineering organization of hundreds of developers. Rather than a central security team reviewing all code (impossible at Agile velocity), each product team had a security champion — a developer with security training who could review security-sensitive changes, answer security questions from teammates, and escalate issues requiring specialist involvement. Security review velocity matched development velocity. This model is now standard in large Agile organizations (Spotify, Netflix, Google).
DevOps
DevOps breaks the wall between development and operations — enabling continuous integration and continuous delivery (CI/CD) of software. Code is integrated, built, tested, and deployed multiple times per day. Traditional security practices (quarterly penetration tests, manual code reviews) cannot keep pace with DevOps velocity. Security tools must be embedded in the pipeline and automated — a security check that takes 2 hours cannot be in a pipeline that runs 50 times per day.
Security challenge in DevOps
Speed is the enemy of manual security gates. Security teams that try to review every deployment become bottlenecks that DevOps teams route around. The security response is automation: SAST in the IDE and CI, DAST against staging environments, SCA for dependency vulnerabilities, secrets scanning to catch credentials in code. Automated security gates that block pipelines on critical findings — while informing but not blocking on medium findings — match security to DevOps velocity.
Real-world example
In 2019, Uber’s developer unknowingly pushed a commit containing an AWS access key to an internal GitHub repository. Without automated secrets scanning in the commit hook, the key remained in the repository for weeks before being discovered during a security audit. A pre-commit hook that scanned for secret patterns would have blocked the commit at the developer’s workstation before it ever reached the repository. Git-secrets, Gitleaks, and Trufflehog are open-source tools that prevent this class of incident at the push moment — a security control that costs milliseconds and prevents incidents that cost millions.
DevSecOps
DevSecOps extends DevOps by making security a shared responsibility of every team member — not a downstream gate or a separate security team function. Security is “shifted left” — moved earlier in the pipeline — and automated wherever possible. The goal: every developer is empowered and equipped to write secure code, every pipeline run includes security testing, and security findings are treated as bugs to be fixed, not compliance checkboxes to be accepted.
The DevSecOps toolchain
Pre-commit: secrets scanning, linting, IaC security scanning (Checkov, tfsec). CI pipeline: SAST (Semgrep, Checkmarx, Veracode), SCA (Snyk, Dependabot), container image scanning (Trivy, Grype). Pre-deployment: DAST against staging (OWASP ZAP, Burp Suite), IAST. Production: runtime security monitoring, WAF, RASP. The full pipeline creates a security-in-depth approach where each tool catches different classes of vulnerability at different stages.
Real-world example
Google’s BeyondProd and Supply Chain Levels for Software Artifacts (SLSA) framework codifies DevSecOps supply chain security requirements. Every Google production binary must have a verifiable build provenance — a cryptographically signed record that traces the binary to specific source code, built by specific systems, through a documented build process. This prevents supply chain attacks by ensuring that a deployed binary can be traced to its exact source code at every point. SLSA has become an industry standard adopted by the Linux Foundation and major cloud providers as the framework for software supply chain integrity.
Scaled Agile Framework (SAFe)
SAFe extends Agile practices to large enterprises — coordinating multiple Agile teams across a program or portfolio. In SAFe, security integrates at three levels: Team (security in sprint practices, security champions), Program (security architecture reviews at PI planning, security non-functional requirements at the feature level), and Portfolio (security compliance requirements, threat landscape assessment informing portfolio priorities).
Security in PI planning
Program Increment (PI) planning — SAFe’s quarterly planning event — is the appropriate time for security architecture reviews, threat model updates, and security requirement alignment across teams. Security is a cross-cutting concern that must be represented in the PI planning event, not handled separately by a security team after features are committed to teams.
Real-world example
A large insurance company implementing SAFe discovered that security requirements were being treated as a separate “security release train” — a parallel track that delivered security features on its own cadence, disconnected from product delivery trains. The result: security features lagged behind product features, creating windows of exposure. Restructuring to embed security architects into each Agile Release Train (ART) and including security non-functional requirements in each feature’s acceptance criteria brought security into the product delivery flow rather than treating it as an external gate.
Maturity models
CMMI (Capability Maturity Model Integration)
Five maturity levels (Initial → Managed → Defined → Quantitatively Managed → Optimizing). Originally for software engineering process maturity, now applied to security. Level 1 (Initial): chaotic, ad hoc processes. Level 5 (Optimizing): continuous improvement driven by data. Most organizations target Level 3 (Defined) as the practical maturity goal for security processes.
SAMM (Software Assurance Maturity Model)
OWASP’s model specifically for software security program maturity. Four business functions (Governance, Design, Implementation, Verification), each with three security practices, each rated at 0–3 maturity. SAMM assessments produce a maturity scorecard and a roadmap of improvements. Used to benchmark a software security program and plan targeted improvements with measurable outcomes.
🌐 Real-world example — SAMM in practice
A global bank used SAMM to assess their software security program across 200 development teams. The assessment revealed: Governance practices were at SAMM Level 2 (policies existed and were communicated), but Implementation practices were at Level 0–1 (no SAST tooling, no secure coding training for developers, no secrets management). The scorecard made the investment case concrete: the gap between governance (what the policy said) and implementation (what developers actually did) was quantified and mapped to specific improvement initiatives. Year 1 investment: SAST tooling rollout and developer secure coding training. Year 2: DAST integration and SCA. The maturity model converted “we need to improve security” into “we need these specific capabilities at these specific teams by this specific date.”
Identify and apply security controls in software development ecosystems
The modern software development ecosystem — languages, libraries, build tools, IDEs, CI/CD pipelines, and code repositories — is itself an attack surface. A compromised development tool, a malicious library dependency, or a secrets leak in a code repository can compromise every application the team builds. Securing the development ecosystem is a prerequisite for producing secure software.
Application security testing methods
Static Application Security Testing
Analyzes source code, bytecode, or binaries without executing the application. Finds security vulnerabilities at the code level: injection flaws, hardcoded credentials, insecure cryptographic usage, and buffer overflows. Runs in the CI pipeline — fast feedback for developers.
Tools: Semgrep, Checkmarx, Veracode SAST, SonarQube, Fortify. Limitation: high false positive rate requires tuning. Cannot find runtime-only vulnerabilities (business logic flaws, authentication issues in deployed state).
Dynamic Application Security Testing
Tests the running application from the outside — sending malicious inputs and observing responses. Finds authentication flaws, injection vulnerabilities, session management issues, and misconfigurations that only manifest at runtime. Does not require source code access.
Tools: OWASP ZAP (open-source), Burp Suite, HCL AppScan. Limitation: cannot find code-level issues; coverage depends on the application’s attack surface being fully exercised. Takes longer than SAST.
Software Composition Analysis
Identifies open-source and third-party components in the application and checks them against vulnerability databases. Generates a Software Bill of Materials (SBOM). Essential for supply chain security — 80%+ of modern application code is open-source dependencies.
Tools: Snyk, OWASP Dependency-Check, GitHub Dependabot, Black Duck. Log4Shell impact was assessable in hours for organizations with SCA integrated into their pipelines vs. weeks for those without it.
Interactive Application Security Testing
Instruments the application with an agent that monitors behavior from inside during testing. Combines SAST’s code-level insight with DAST’s runtime perspective. Lower false positive rate than SAST; more coverage than DAST alone. Agent adds performance overhead.
Tools: Contrast Security, Seeker. Best used in QA/staging environments where performance impact is acceptable. Provides precise code-level location of vulnerabilities discovered at runtime — “line 247 of UserController.java is vulnerable to SQL injection.”
CI/CD security controls
Pipeline security gates
Automated security checks that must pass before code advances in the pipeline. Critical SAST findings block the build. Medium findings produce warnings. Pipeline gates enforce “secure code is the only code that ships” without requiring manual review of every change.
Secrets scanning
Pre-commit and CI-stage scanning for API keys, credentials, certificates, and tokens accidentally committed to code repositories. Once a secret is pushed to a remote repository, it must be treated as compromised — even if immediately deleted, the Git history retains it.
IaC security scanning
Infrastructure as Code (Terraform, CloudFormation, Kubernetes manifests) is scanned for misconfigurations before deployment. Checkov, tfsec, KICS identify publicly exposed S3 buckets, overpermissioned IAM roles, and unencrypted storage in IaC templates — before they become production misconfigurations.
Container image scanning
Container images are scanned for OS-level vulnerabilities, vulnerable application libraries, misconfigurations, and embedded secrets before being pushed to a registry or deployed. Trivy, Grype, and Clair provide image scanning. Registry policies can block images with critical vulnerabilities from being deployed.
🌐 Real-world example — CI/CD pipeline attack
The 2020 SolarWinds SUNBURST attack compromised the CI/CD build pipeline rather than the application code. Attackers accessed SolarWinds’ Orion build system and injected malicious code into the build process — the source code was clean, but the compiled binary contained the backdoor. The malicious binary was digitally signed by SolarWinds’ legitimate signing certificate and passed all standard integrity checks. Build pipeline integrity controls (build attestation, reproducible builds, provenance verification) are the specific controls designed to detect this class of attack. SLSA (Supply Chain Levels for Software Artifacts) provides a framework of build integrity requirements specifically designed in response to the SolarWinds attack pattern.
Code repositories and branch protection
Code repositories (GitHub, GitLab, Azure DevOps, Bitbucket) are critical assets — they contain all application source code, infrastructure configuration, and often secrets that were accidentally committed. Repository security controls: branch protection rules (require pull request reviews before merging to main, require status checks to pass, prevent force-push), signed commits (GPG signing verifies commit author identity), repository access controls (least privilege — contributors should not have admin access), and dependency review (automated review of dependency changes for vulnerabilities).
Assess the effectiveness of software security
Assessing software security effectiveness determines whether the controls and practices in place are actually achieving their intended security outcomes — not merely whether they are present. A SAST tool installed but ignored, a code review process that rubber-stamps all changes, or a security training program with 95% completion but no behavioral change are all controls that exist on paper but provide no actual security value.
Auditing and logging of changes
Every change to application code, configuration, and infrastructure must be logged — who made the change, when, what was changed, and through what approval process. Git commit history provides code change audit trails. CI/CD pipeline logs provide deployment audit trails. Together they establish: was every production change authorized, reviewed, and deployed through the controlled pipeline — or were there unauthorized direct changes to production?
Risk analysis and mitigation
Security findings from testing tools, code reviews, and threat models must be risk-assessed and prioritized. Not all findings warrant immediate remediation — a CVSS 7.0 vulnerability in an internal tool used by 3 people is lower priority than a CVSS 5.0 vulnerability in an authentication endpoint used by 10 million customers. Risk-based prioritization requires understanding the business context of each vulnerable component, not just its technical severity.
Metrics for software security effectiveness
Mean time to remediate (MTTR)
Average time from vulnerability discovery to verified remediation. Measured per severity level. A critical MTTR of 30 days indicates the patch SLA is not being met. Trending MTTR over time reveals whether the security program is improving or degrading.
Vulnerability density
Number of security findings per thousand lines of code, per release, or per application. Allows comparison across teams and applications. Trending down over time indicates that secure coding practices are having effect. Sudden spikes may indicate a new developer, a new framework, or a new vulnerability class being discovered.
Security debt
The accumulated backlog of known, unresolved security findings. Like technical debt, security debt accumulates interest — older vulnerabilities become more likely to be discovered and exploited as exploit toolkits are developed. Security debt reporting to management creates accountability for backlog management.
SAST/DAST escape rate
The percentage of production vulnerabilities that were NOT caught by pre-production testing tools. A high escape rate indicates that testing coverage is insufficient — either the tools are not tuned, the coverage is incomplete, or new vulnerability classes are not represented in the tooling. Escape rate drives investment in testing tool improvement.
🌐 Real-world example — security debt consequences
The 2017 Equifax breach exploited a vulnerability (CVE-2017-5638 in Apache Struts) that had been known and patchable for 63 days before exploitation. Equifax’s vulnerability management data showed the affected application, but Equifax did not have a complete, accurate mapping of which applications used Apache Struts — a data gap in their software composition tracking. An SBOM (Software Bill of Materials) generated by SCA tooling would have produced an immediate list of all applications using Apache Struts, enabling targeted remediation. Instead, Equifax’s manual processes failed to identify the affected internet-facing application. The $700 million FTC settlement included a requirement to implement SCA tooling. Security debt without visibility is the most dangerous kind.
Assess security impact of acquired software
Most organizations use far more software than they build. COTS products, open-source libraries, third-party services, and cloud platforms each introduce a supply chain dependency — the organization inherits whatever vulnerabilities exist in the software it uses. Security assessment of acquired software is not a procurement formality; it is the front line of supply chain risk management.
COTS (Commercial Off-the-Shelf)
Vendor-built commercial products. Organization has no access to source code — cannot fix vulnerabilities, only apply vendor patches. Assessment: vendor security questionnaire, penetration test of the product in a test environment, review of vendor’s vulnerability disclosure history, and patch release timeliness. Contract must include security requirements, vulnerability notification SLA, and right-to-audit.
Key risk: vendor discontinues the product (EOL) or is slow to patch critical vulnerabilities. Contractual remedies are the only leverage.
Open source
Source code available — can audit the code, but few organizations have the capacity to audit every dependency. SCA tooling automates vulnerability identification. License compliance is also a risk — GPL licenses may impose open-source obligations on proprietary code that incorporates GPL components. Key assessment: is the project actively maintained? Are vulnerabilities patched promptly? What is the contributor community size?
Key risk: unmaintained packages with known vulnerabilities (the left-pad incident), license compliance failures, and malicious packages published to package registries (npm, PyPI typosquatting).
Third-party software
Software built by an external party specifically for the organization (custom development, system integrators). The organization may have source code rights but not necessarily the expertise to audit it. Assessment: require security testing as a contract deliverable, conduct independent security review before deployment, require an SBOM of all dependencies, and retain source code escrow rights.
Key risk: contractor security practices are unknown and unverified unless contractually required. Third-party code inherits all of the contractor’s dependency vulnerabilities.
Cloud services (SaaS/PaaS/IaaS)
The organization’s data and processes run on infrastructure they do not control. Security assessment: SOC 2 Type II report (most useful — covers a 6–12 month operating period), ISO 27001 certificate, penetration test reports (shared under NDA), security questionnaire aligned to CSA CAIQ. Data processing agreement required for any personal data. Right-to-audit clause or equivalent third-party audit requirement.
Key risk: shared responsibility model misunderstanding, data residency, and the blast radius of a major cloud provider breach affecting all customers simultaneously.
Managed services
Enterprise applications managed by a third-party service provider — ERP, payroll, HRIS. The provider operates the software on the organization’s behalf. Assessment: same as cloud services, with additional focus on the provider’s access to the organization’s data, their employee background screening, and their incident notification procedures.
Key risk: the provider’s employees have access to sensitive organizational data. Insider threat within the managed service provider is the primary risk.
🌐 Real-world example — malicious open-source package
In 2022, a malicious npm package called “node-ipc” — maintained by a single developer — was modified to contain destructive malware that would overwrite files on systems in Russia and Belarus. The package had millions of weekly downloads because it was a dependency of the popular “vue-cli” package. Developers who ran npm install and happened to be in Russia or Belarus had their files overwritten. The incident (dubbed “protestware”) illustrated two supply chain risks: the fragility of widely used packages maintained by single individuals, and the lack of security review for dependency updates. Dependency pinning (locking to a specific version hash), automated dependency review (GitHub Dependabot, Renovate), and SBOM generation are controls that allow organizations to assess and control the impact of open-source dependency changes before they reach production.
Define and apply secure coding guidelines and standards
Secure coding guidelines translate security principles into specific, actionable requirements for developers. They convert “don’t introduce vulnerabilities” from a vague aspiration into concrete, reviewable practices: parameterize all SQL queries, validate all inputs on the server side, use the framework’s CSRF protection, never log sensitive data. Guidelines must be language-specific, regularly updated as new vulnerability classes emerge, and integrated into code review criteria.
OWASP Top 10 web vulnerabilities
| Rank | Vulnerability | Description | Secure coding prevention | Real-world example |
|---|---|---|---|---|
| A01 | Broken Access Control | Users can act outside their intended permissions — access other users’ data, access admin functions, or bypass authorization checks. | Enforce object-level authorization on every request. Default deny. Test every endpoint for authorization, not just authentication. | Facebook (2019): API returned any user’s private data by user ID with no authorization check. 29M accounts affected. |
| A02 | Cryptographic Failures | Sensitive data exposed due to weak or absent encryption — passwords stored as MD5, data transmitted in cleartext, weak keys. | Bcrypt/Argon2 for passwords. AES-256 for sensitive data at rest. TLS 1.2+ in transit. Never roll your own crypto. Use validated libraries. | RockYou2021 — 8.4 billion passwords in a single breach compilation, largely from sites storing passwords as MD5 without salting. |
| A03 | Injection | Untrusted data sent to an interpreter as part of a command or query — SQL injection, OS command injection, LDAP injection. | Parameterized queries / prepared statements. Stored procedures. Input validation (whitelist, not blacklist). ORMs with safe query building. | 2008 Heartland: SQL injection led to 130M card numbers stolen. 2011 Sony PSN: SQL injection exposed 77M accounts. |
| A04 | Insecure Design | Security flaws that are inherent in the design — not implementation bugs but fundamental design decisions that make secure implementation impossible. | Threat modeling at design phase. Security requirements in user stories. Security design patterns (defense in depth, fail-safe defaults). Security architecture review before development begins. | A password reset flow that uses a predictable “secret question” is an insecure design — no secure implementation of that design is possible. |
| A05 | Security Misconfiguration | Insecure default configurations, incomplete configurations, open cloud storage, unnecessary features enabled, default credentials unchanged. | IaC for consistent, reviewed configurations. Automated misconfiguration scanning (CSPM). Hardening standards applied at build. Default credentials always changed. Unnecessary features disabled. | Capital One (2019): misconfigured WAF. 140M records. 2017: 197M voter records exposed in publicly readable S3 bucket. |
| A06 | Vulnerable Components | Using components with known vulnerabilities — outdated libraries, frameworks, operating systems with unpatched CVEs. | SCA in CI pipeline. Automated dependency updates (Dependabot, Renovate). SBOM generation. Dependency inventory with known vulnerability monitoring. | Log4Shell (2021): log4j 2 vulnerability affected billions of Java applications. Organizations with SCA assessed impact in hours; others took weeks. |
| A07 | Identification and Authentication Failures | Weaknesses in authentication — broken session management, credential stuffing, weak passwords allowed, missing MFA. | MFA for all privileged accounts. Account lockout after failed attempts. Strong password policy. Secure session token generation (cryptographically random, sufficient length, short expiry). Server-side session invalidation on logout. | Rockstar Games (2022): GTA 6 footage leaked by a teenager who authenticated to Slack using stolen employee credentials — no MFA on the account. |
| A08 | Software and Data Integrity Failures | Code and infrastructure not protected against integrity violations — unsigned updates, insecure deserialization, CI/CD pipeline not secured. | Code signing for all artifacts. Verify integrity of downloaded components (hash verification). Secure CI/CD pipeline (build provenance, signed artifacts). Insecure deserialization: avoid deserializing untrusted data; use safe libraries. | SolarWinds SUNBURST (2020): malicious code injected into build pipeline, signed with legitimate certificate. Affected 18,000 organizations. |
| A09 | Security Logging and Monitoring Failures | Insufficient logging of security events — failed logins not logged, suspicious activity not alerted on, logs not protected from tampering. | Log all authentication events (success and failure), access control decisions, input validation failures, and application errors. Protect logs from modification. Ship logs to a SIEM. Alert on security-relevant events in near real-time. | The Equifax breach was active 78 days before detection. Logs existed but SSL inspection failure left a monitoring blind spot. Duration directly extended scope and cost of the breach. |
| A10 | Server-Side Request Forgery (SSRF) | Application fetches a remote resource without validating the URL — attackers can use the server to probe internal services, cloud metadata endpoints, or internal infrastructure. | Validate and sanitize all user-supplied URLs. Allowlist of permitted external destinations. Block cloud metadata service IPs in firewall rules. Disable URL schemes not required (file://, dict://, ftp://). | Capital One (2019): SSRF against misconfigured WAF reached AWS EC2 metadata service, leaked IAM credentials. 100M+ records exposed. |
API security
APIs are the primary interface between modern application components and the outside world — and the primary target for authorization attacks. The OWASP API Security Top 10 addresses API-specific vulnerabilities that the web application Top 10 does not fully cover.
BOLA (Broken Object Level Authorization)
API returns an object (user record, order, document) based on an ID parameter without verifying the caller is authorized to access that specific object. The #1 API vulnerability. Prevention: enforce object-level authorization checks on every API call — do not assume the caller can access any object just because they are authenticated.
Excessive data exposure
API returns more fields than the client needs — exposing sensitive attributes that should not be transmitted. Prevention: define response schemas explicitly; never return a full database object and rely on the client to filter. Return only what is needed for the specific operation.
Rate limiting absent
No limit on how many requests a caller can make — enables brute force of authentication, enumeration of user IDs, and DDoS of API endpoints. Prevention: rate limiting at the API gateway level (requests per second per API key, per IP, per user). Exponential backoff on authentication failures.
Mass assignment
API allows clients to update object properties that should not be user-modifiable — sending {“role”: “admin”} in a profile update request. Prevention: use allowlists of permitted update fields; never directly bind request body to database objects (the “mass assignment” anti-pattern).
Secure coding practices
Software-defined security
Software-defined security applies the principles of software-defined networking and infrastructure-as-code to security policy — defining security controls programmatically rather than through manual device configuration. Security policies are version-controlled, testable, and deployed through the same CI/CD pipelines as application code. Examples: security groups defined in Terraform (validated by IaC security scanning before deployment), WAF rules as code (reviewed in pull requests), network micro-segmentation policies deployed via SDN APIs.
🌐 Real-world example — software-defined security at scale
Netflix’s security tooling (including their open-source “Security Monkey” cloud security posture management tool) implements software-defined security at scale: security policies for AWS resources are defined as code, continuously monitored for drift, and violations automatically trigger alerts or remediation workflows. When a new AWS account is provisioned, security policies are applied automatically via code — not manually configured by a security engineer. This approach scales security governance to thousands of AWS accounts without proportional growth in the security team. The alternative — manually reviewing and configuring each account — would require a security team orders of magnitude larger.
The software development security chain
Every gap in this chain is a vulnerability class that will be introduced in development and discovered later — by security testing, by users, or by attackers.
Define security requirements before design
What data is processed, what regulations apply, what are the threat actors? Security requirements at phase 1 cost hours to address. The same requirements discovered at phase 4 cost months.
Threat model at design time
STRIDE, PASTA, or Attack Trees applied to the architecture before code is written. Design flaws identified here are free to fix. Design flaws discovered in production require re-architecture.
Match methodology to security integration
Waterfall needs security gates. Agile needs security user stories and security champions. DevSecOps needs automated pipeline security. The methodology determines where security integrates — not whether it does.
Automate security testing in the pipeline
SAST + SCA in CI (fast, automated). DAST in pre-production (deeper). IAST in QA for high-risk applications. No single tool covers everything — layer them.
Secure the development ecosystem itself
Protect the CI/CD pipeline, repository, secrets, and build artifacts. A compromised pipeline compromises every application it builds — as SolarWinds demonstrated.
Assess every piece of acquired software
COTS, open source, third-party, cloud services — all carry inherited risk. SCA for dependencies, SOC 2 for cloud vendors, contractual security requirements for all suppliers.
Apply OWASP Top 10 as a baseline
Input validation, parameterized queries, output encoding, secure defaults, proper authentication and authorization, no hardcoded secrets. The Top 10 has not changed dramatically in 20 years — the industry keeps making the same mistakes.
Measure and improve maturity continuously
SAMM assessments to benchmark current state. Metrics (MTTR, vulnerability density, escape rate) to measure improvement. Security debt tracked and reported to leadership. Improvement is only visible when it is measured.
By profession, a CloudSecurity Consultant; by passion, a storyteller. Through SunExplains, I explain security in simple, relatable terms — connecting technology, trust, and everyday life.
Leave a Reply