What is SDL? Introduction to Secure Development Lifecycle

Security cannot be bolted on at the end of development—it must be integrated throughout. The Secure Development Lifecycle (SDL) provides a structured approach to building security into products from the ground up.

What is SDL?

The Secure Development Lifecycle (SDL) is a process that integrates security activities into every phase of software and product development. Unlike traditional development where security is often an afterthought, SDL makes security a foundational consideration alongside functionality and performance.

The SDL Philosophy

Traditional Approach:
Requirements → Design → Code → Test → Release → (Security Review) → Patch

SDL Approach:
Security Requirements → Security Design → Secure Coding → Security Testing → Secure Release → Monitoring

Why SDL Matters

Without SDL	With SDL
Security tested late, expensive fixes	Security validated early, cost-effective
Vulnerabilities discovered in production	Vulnerabilities found before release
Reactive patching cycles	Proactive security posture
Undefined security responsibilities	Clear security roles and processes

The Cost Equation

Finding and fixing security issues becomes exponentially more expensive as development progresses:

        Cost to Fix
            │
    $1000+ │                         ○ Production
            │                      ○ ○
      $100 │                    ○ ○
            │                 ○ ○
       $10 │              ○ ○
            │           ○ ○
        $1 │        ○ ○
            └──────────────────────────▶ Phase
           Design  Code  Test  Deploy

IEC 62443-4-1: The SDL Standard for Industrial Products

IEC 62443-4-1 provides specific SDL requirements for industrial automation products. Let’s explore its 8 core practices:

Practice 1: Security Management (SM)

Security doesn’t happen without organizational commitment.

Key Requirements:

• SM-1: Defined SDL process covering the entire product lifecycle
• SM-2: Clear assignment of security roles and responsibilities
• SM-4: Access to security expertise
• SM-13: Continuous improvement based on metrics

What This Looks Like:

Before: "We care about security"
After: Document showing:
- SDL phases with security checkpoints
- RACI matrix for security decisions
- Security training records for developers
- Quarterly SDL improvement metrics

Practice 2: Security Requirements (SR)

You can’t build what you haven’t specified.

Key Requirements:

• SR-1: Product security context defined (operating environment assumptions)
• SR-2: Threat modeling conducted
• SR-3: Security requirements derived from threats

Threat Modeling Example (STRIDE):

Threat Type	Example in Industrial Product
Spoofing	Fake HMI login to gain system access
Tampering	Modifying control commands to damage equipment
Repudiation	Attacker denies sending dangerous command
Information Disclosure	Exposing sensitive process data
Denial of Service	Flooding network to disrupt control
Elevation of Privilege	Low-privilege user gaining admin rights

Practice 3: Secure by Design (SD)

Security flaws in design are impossible to fix in code.

Key Requirements:

• SD-1: Security design principles applied
• SD-2: Defense-in-depth architecture

Security Design Principles:

1. Least Privilege: Components only have access they need
2. Defense in Depth: Multiple security layers
3. Secure by Default: Secure configuration out of the box
4. Fail Securely: System fails to safe state

Defense in Depth Example:

Layer 1: Network Segmentation (VLANs, Firewalls)
    ↓
Layer 2: Device Authentication (Certificates, Keys)
    ↓
Layer 3: Application Authorization (RBAC)
    ↓
Layer 4: Data Encryption (TLS, Encrypted Storage)

Practice 4: Secure Implementation (SI)

Secure designs must be implemented securely.

Key Requirements:

• SI-2: Secure coding standards defined and followed
• SI-3: Secure source code management

Common Coding Issues to Avoid:

Issue	Risk	Mitigation
Buffer overflows	Code execution	Use safe string functions
Hardcoded credentials	Easy access for attackers	Use secure credential storage
Missing input validation	Injection attacks	Validate all inputs
Integer overflows	Unexpected behavior	Use checked arithmetic

Practice 5: Security Verification (SVV)

Trust but verify—test your security assumptions.

Key Requirements:

• SVV-1: Security requirements tested
• SVV-2: Threat mitigation validated
• SVV-3: Automated vulnerability testing tools used
• SVV-4: Penetration testing conducted

Testing Pyramid for Security:

                    ▲
                   ╱ ╲
                  ╱   ╲
                 ╱ SAST╲      Static Analysis
                ╱───────╲
               ╱         ╲
              ╱   DAST    ╲    Dynamic Analysis
             ╱─────────────╲
            ╱               ╲
           ╱   Pen Testing   ╲  Manual Security Testing
          ╱───────────────────╲
         ╱                     ╲
        ╱───────────────────────╲
       ╱     Security Unit Tests  ╲
      ╱─────────────────────────────╲

Practice 6: Defect Management (DM)

Vulnerabilities will be found—manage them systematically.

Key Requirements:

• DM-1: Process to receive security issue reports
• DM-3: Severity assessment (CVSS scoring)
• DM-4: Remediation according to defined timelines

Typical SLAs:

Severity	Response Time	Fix Time
Critical	48 hours	7 days
High	3 business days	30 days
Medium	1 week	90 days
Low	2 weeks	Next release

Practice 7: Security Update Management (SUM)

Getting updates to customers securely is as important as fixing vulnerabilities.

Key Requirements:

• SUM-1: Updates tested before release
• SUM-4: Updates delivered with integrity protection (signing)

Secure Update Process:

1. Vulnerability Fixed
2. Patch Tested (Regression + Security)
3. Update Signed (Private Key in HSM)
4. Update Published (with Checksums)
5. Customer Verifies Signature
6. Update Applied

Practice 8: Security Guidelines (SG)

Help customers use your product securely.

Key Requirements:

• SG-3: Security hardening guidelines provided
• SG-5: Secure operation guidelines provided

What Good Guidelines Include:

• Default password handling
• Network configuration recommendations
• Required security settings
• Ongoing security maintenance

SDL Maturity Levels

IEC 62443-4-1 defines four maturity levels:

Level	Name	Characteristics
ML1	Initial	Ad-hoc, undocumented
ML2	Managed	Documented, trained staff
ML3	Defined/Practiced	Repeatable, used in production
ML4	Improving	Quantitatively managed

Target for Certification: ML3 is typically required for component certification.

Getting Started with SDL

Phase 1: Assessment (1-2 months)

1. Review current development process
2. Identify gaps against IEC 62443-4-1
3. Define target maturity level
4. Get management commitment

Phase 2: Foundation (2-3 months)

1. Document SDL policy
2. Define security roles
3. Select tools (SAST, SCA, etc.)
4. Establish security training program

Phase 3: Implementation (3-6 months)

1. Pilot SDL on one project
2. Conduct threat modeling
3. Implement security testing
4. Establish metrics

Phase 4: Optimization (ongoing)

1. Roll out SDL organization-wide
2. Measure effectiveness
3. Continuous improvement
4. Prepare for certification

Common SDL Challenges and Solutions

Challenge	Solution
Developer resistance	Start with training, show value
Schedule pressure	Integrate security into existing gates
Tool costs	Start with open-source tools
Expertise gap	Use external consultants initially

Key Takeaways

1. SDL is a process, not a project—it requires ongoing commitment
2. Start small—implement practices incrementally
3. Measure everything—use data to drive improvement
4. Security is everyone’s responsibility—not just “the security team”
5. SDL pays for itself—early detection reduces overall cost

Next Steps

In our next article, we’ll explore the critical differences between IT security and OT security, and why industrial environments require specialized approaches.

---

SDL implementation requires organizational commitment but delivers lasting security improvements. Start where you are and improve iteratively.