Secure by Design: Embedding Cybersecurity in Every Phase of the SDLC

Introduction: The Shift Left Movement

In the rapidly evolving digital landscape, cybersecurity can no longer be an afterthought. The traditional approach of “bolt-on security”—where security controls are added after development is complete—has proven inadequate against sophisticated modern threats. This realisation has driven the Secure by Design movement, which advocates for embedding security into every phase of the software development lifecycle (SDLC).

The cost of fixing security vulnerabilities increases exponentially the later they are discovered. Research from IBM and the Ponemon Institute shows that vulnerabilities found in production cost approximately 30 times more to remediate than those identified during the design phase. Beyond financial implications, late-stage security fixes often require architectural changes that compromise system integrity and delay critical releases.

In 2023 and 2024, regulatory bodies worldwide have formalised these principles into law. The UK's Product Security and Telecommunications Infrastructure (PSTI) Act 2022, which came into force in April 2024, represents one of the most significant steps towards mandating secure-by-design practices. Combined with CISA's influential guidelines and ETSI's technical standards, organisations now have a comprehensive framework for building security into their products and services from inception.

CISA's Secure by Design Principles

In October 2023, the Cybersecurity and Infrastructure Security Agency (CISA), alongside 17 international partners, released the updated “Shifting the Balance of Cybersecurity Risk” guidance. This landmark document establishes three core principles that software manufacturers should embrace to create genuinely secure products.

Demonstrating Commitment

CISA's guidance emphasises that software manufacturers must demonstrate their commitment to these principles through concrete actions:

• •Secure defaults: Products should be secure out of the box, with security features enabled by default rather than requiring manual configuration.
• •Eliminate default credentials: No product should ship with universal default passwords or credentials.
• •Secure development practices: Implement formal secure development lifecycle practices, including code review, testing, and vulnerability management.
• •Transparency: Publish vulnerability disclosure policies, security advisories, and product security documentation.

UK Product Security (PSTI) Act 2022

The Product Security and Telecommunications Infrastructure Act 2022 represents the UK's legislative response to the growing threat of insecure connected products. Coming into force on 29 April 2024, it establishes mandatory security requirements for manufacturers, importers, and distributors of consumer connectable products sold in the UK market.

Core Requirements

Products in Scope

The PSTI Act applies to a wide range of consumer connectable products, including:

• ✓Smart home devices and appliances
• ✓Wearable technology
• ✓Smart TVs and streaming devices
• ✓Connected cameras and doorbells
• ✓Baby monitors
• ✓Smart speakers and voice assistants
• ✓Connected toys
• ✓Routers and network equipment

ETSI EN 303 645 Standards

ETSI EN 303 645 “Cyber Security for Consumer Internet of Things: Baseline Requirements” provides the technical foundation for IoT security standards globally. Published by the European Telecommunications Standards Institute, this standard has been adopted as the baseline for numerous regulatory frameworks, including the UK PSTI Act.

The 13 Baseline Provisions

These provisions form a comprehensive baseline that addresses the most critical security concerns in IoT devices. By implementing these standards, manufacturers can significantly reduce the attack surface of their products whilst demonstrating compliance with emerging regulatory requirements across multiple jurisdictions.

Security in Every SDLC Phase

Implementing secure-by-design principles requires integrating security activities into every phase of the software development lifecycle. Below is a comprehensive breakdown of security activities for each phase:

Threat Modelling Methodologies

Threat modelling is a structured approach to identifying, quantifying, and addressing security threats to a system. It should be conducted early in the design phase and revisited throughout the development lifecycle as the system evolves.

STRIDE Framework

Developed by Microsoft, STRIDE categorises threats into six categories:

PASTA (Process for Attack Simulation and Threat Analysis)

PASTA is a seven-stage, risk-centric threat modelling methodology that aligns business objectives with technical requirements:

1. 1Define business objectives
2. 2Define technical scope
3. 3Application decomposition
4. 4Threat analysis
5. 5Vulnerability and weakness analysis
6. 6Attack modelling and simulation
7. 7Risk analysis and countermeasure development

Secure Coding Practices

Secure coding is the practice of writing software in a way that protects against the introduction of security vulnerabilities. Following established secure coding standards significantly reduces the attack surface of applications.

OWASP Secure Coding Principles

// Example: Comprehensive input validation in TypeScript// Define validation schema with Zod// Server-side validation function// Server-side validation function// Server-side validation function// Server-side validation function// Server-side validation function// Server-side validation function// Server-side validation function// Server-side validation function// Server-side validation function// Server-side validation function// Server-side validation function// Server-side validation function// Server-side validation function// Server-side validation function// Server-side validation function// Server-side validation function// Server-side validation function// Server-side validation function// Express middleware example// Express middleware example// Express middleware example// Express middleware example// Express middleware example// Express middleware example// Express middleware example// Express middleware example Express middleware example
app.post('/api/register', (req, res, next) => {
  try {
    const validatedData = validateUserInput(req.body);
    // Process validated data...
  } catch (error) {
    if (error instanceof ValidationError) {
      return res.status(400).json({ errors: error.details });
    }
    next(error);
  }
});

// Context-specific output encoding examples// HTML context - escape special characters// HTML context - escape special characters// JavaScript context - JSON encode// JavaScript context - JSON encode// JavaScript context - JSON encode// JavaScript context - JSON encode// JavaScript context - JSON encode// URL context - URI encode// URL context - URI encode// URL context - URI encode// URL context - URI encode// Sanitise HTML when rich text is required// Sanitise HTML when rich text is required// Sanitise HTML when rich text is required// React automatically escapes - but beware dangerouslySetInnerHTML// React automatically escapes - but beware dangerouslySetInnerHTML// React automatically escapes - but beware dangerouslySetInnerHTML// React automatically escapes - but beware dangerouslySetInnerHTML// BAD: <div dangerouslySetInnerHTML={{ __html: userInput }} />// GOOD: <div>{userInput}</div>/ GOOD: <div>{userInput}</div>

// Secure session configuration (Express.js example)// Password hashing with Argon2// Password hashing with Argon2// Password hashing with Argon2// Password hashing with Argon2// Password hashing with Argon2// Password hashing with Argon2// Password hashing with Argon2// Password hashing with Argon2// Password hashing with Argon2// Password hashing with Argon2// Password hashing with Argon2// Password hashing with Argon2// Password hashing with Argon2// Password hashing with Argon2// Password hashing with Argon2// Password hashing with Argon2// Password hashing with Argon2// Password hashing with Argon2// CSRF protection// Password hashing with Argon2// Password hashing with Argon2// Password hashing with Argon2// Password hashing with Argon2// Password hashing with Argon2// Password hashing with Argon2 hashing with Argon2
import argon2 from 'argon2';

async function hashPassword(password: string): Promise<string> {
  return argon2.hash(password, {
    type: argon2.argon2id,
    memoryCost: 65536,    // 64 MB
    timeCost: 3,          // 3 iterations
    parallelism: 4,       // 4 parallel threads
  });
}

async function verifyPassword(hash: string, password: string): Promise<boolean> {
  return argon2.verify(hash, password);
}

// Secure cryptography examples (Node.js)// AES-256-GCM encryption (authenticated encryption)// Secure random token generation// Secure random token generation// Secure random token generation// Secure random token generation// Secure random token generation// Secure random token generation// Secure random token generation// Secure random token generation// Secure random token generation// Secure random token generation// Secure random token generation// Secure random token generation// Secure random token generation// Secure random token generation// Secure random token generation// Secure random token generation// Secure random token generation// Secure random token generation// Secure random token generation// Secure random token generation// Secure random token generation// Secure random token generation// Secure random token generation// Secure random token generation// Secure random token generation// Secure random token generation// Secure random token generation// HMAC for data integrity// HMAC for data integrity// HMAC for data integrity// HMAC for data integrity// HMAC for data integrity// HMAC for data integrityata integrity
function createHMAC(data: string, key: Buffer): string {
  return crypto.createHmac('sha256', key).update(data).digest('hex');
}

SQL Injection Prevention

// VULNERABLE - Never do this!// SAFE - Parameterised query with Prisma// SAFE - Parameterised query with Prisma// SAFE - Parameterised query with raw SQL// SAFE - Parameterised query with raw SQL// SAFE - Parameterised query with raw SQL// SAFE - Using pg library with parameters// SAFE - Using pg library with parameters// SAFE - Using pg library with parameters// SAFE - TypeORM query builder// SAFE - TypeORM query builder// SAFE - TypeORM query builder// SAFE - TypeORM query builder// SAFE - TypeORM query builderder
const user = await userRepository
  .createQueryBuilder('user')
  .where('user.email = :email', { email: userEmail })
  .getOne();

Troubleshooting Common Security Issues

// Next.js - next.config.js
const securityHeaders = [
  { key: 'X-DNS-Prefetch-Control', value: 'on' },
  { key: 'Strict-Transport-Security', value: 'max-age=63072000; includeSubDomains; preload' },
  { key: 'X-Frame-Options', value: 'SAMEORIGIN' },
  { key: 'X-Content-Type-Options', value: 'nosniff' },
  { key: 'X-XSS-Protection', value: '1; mode=block' },
  { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
  { key: 'Permissions-Policy', value: 'camera=(), microphone=(), geolocation=()' },
  { 
    key: 'Content-Security-Policy', 
    value: "default-src 'self'; script-src 'self' 'unsafe-eval'; style-src 'self' 'unsafe-inline';"
  },
];

module.exports = {
  async headers() {
    return [{ source: '/:path*', headers: securityHeaders }];
  },
};

# 1. Set up pre-commit hooks with gitleaks# .pre-commit-config.yaml# 2. Use environment variables# 2. Use environment variables# 2. Use environment variables# 2. Use environment variables# .env.local (git ignored)# 3. For production, use a secrets manager//user:pass@host:5432/db# 3. For production, use a secrets manager# AWS Secrets Manager example# AWS Secrets Manager example# 4. Rotate any exposed secrets immediately!# 4. Rotate any exposed secrets immediately!# 4. Rotate any exposed secrets immediately!# 4. Rotate any exposed secrets immediately!# 4. Rotate any exposed secrets immediately!# 4. Rotate any exposed secrets immediately!# 4. Rotate any exposed secrets immediately!# 4. Rotate any exposed secrets immediately!# 4. Rotate any exposed secrets immediately!crets immediately!

# Scan for vulnerabilities# Use Snyk for deeper analysis# Automate with Dependabot (.github/dependabot.yml)# Automate with Dependabot (.github/dependabot.yml)bot.yml)
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 10
    groups:
      security:
        applies-to: security-updates
      dependencies:
        applies-to: version-updates
        patterns:
          - "*"

Secure-by-Design Checklist

Implementation Roadmap

Transitioning to a secure-by-design approach requires organisational commitment and a structured implementation plan. The following roadmap provides a phased approach to embedding security throughout your development process:

Measuring Security Success

Effective security programmes require measurable outcomes. The following metrics help organisations track their progress towards secure-by-design maturity:

Conclusion

Secure by Design is no longer optional—it's a regulatory requirement and competitive necessity. The convergence of CISA guidelines, UK PSTI Act requirements, and ETSI standards has created a comprehensive framework for building security into products from inception.

Organisations that embrace secure-by-design principles will benefit from reduced remediation costs, improved customer trust, regulatory compliance, and stronger market positioning. The investment in upfront security pays dividends throughout the product lifecycle and beyond.

The journey towards secure-by-design maturity requires commitment, investment, and cultural change. However, with the right approach, tools, and mindset, organisations can build security into their DNA and deliver products that customers can trust.

References & Further Reading