Document: 31-security-hardening.md
Version: 1.0.0

Purpose

This document defines the security hardening standards used across all Rundown projects.

Security hardening reduces the attack surface of applications and infrastructure by applying secure defaults, enforcing least privilege, and implementing proactive security practices throughout the software lifecycle.

Security is a shared engineering responsibility rather than a single implementation task.

Security Philosophy

Security is a property of the system.

It emerges from disciplined engineering decisions across architecture, infrastructure, deployment, operations, and maintenance.

Security should be incorporated throughout the development lifecycle rather than applied immediately before production.

Responsibilities

Security hardening influences:

• Infrastructure

• Authentication

• Authorization

• Networking

• Deployment

• Data protection

• Secrets management

• Monitoring

• Recovery

Every layer contributes to the overall security posture of the application.

Non-Responsibilities

Security hardening should not:

• Replace secure application design.

• Replace monitoring.

• Replace backups.

• Replace developer education.

• Eliminate operational risk.

No single security measure is sufficient on its own.

Principle of Least Privilege

Every system component should receive only the permissions required to perform its responsibilities.

Examples include:

• User roles

• API credentials

• Database accounts

• Storage access

• Deployment permissions

Excessive permissions increase operational risk.

Secrets Management

Secrets should:

• Remain outside source control.

• Be environment-specific.

• Rotate periodically where appropriate.

• Be accessible only to authorized systems and personnel.

Examples:

• API keys

• Database credentials

• Storage credentials

• Email provider tokens

Server Security

Production servers should:

• Use Ubuntu LTS.

• Apply security updates regularly.

• Disable unused services.

• Restrict open ports.

• Limit SSH access.

• Use key-based authentication.

• Disable password-based SSH login where practical.

Servers should expose only the minimum required attack surface.

Network Security

Networking should:

• Enforce HTTPS.

• Route traffic through Cloudflare.

• Restrict administrative services.

• Use secure firewall rules.

• Separate internal and public services.

Network configuration should prioritize simplicity and controlled access.

Container Security

Containers should:

• Use trusted base images.

• Minimize installed packages.

• Run with the least privileges practical.

• Keep dependencies updated.

• Avoid embedding secrets within images.

Container images should be treated as immutable deployment artifacts.

Application Security

Applications should:

• Validate all input.

• Sanitize user-provided data.

• Protect against common web vulnerabilities.

• Use secure authentication.

• Enforce authorization consistently.

Security validation should occur on the server regardless of frontend checks.

Dependency Management

Dependencies should:

• Be actively maintained.

• Receive security updates.

• Remove unused packages.

• Avoid unnecessary libraries.

Every dependency increases the application's attack surface.

Security Headers

Production applications should configure appropriate HTTP security headers.

Typical examples include:

• Content Security Policy (CSP)

• Strict-Transport-Security (HSTS)

• X-Content-Type-Options

• Referrer-Policy

• Permissions-Policy

Headers should align with application requirements while maintaining compatibility.

Logging & Auditing

Security-relevant events should be logged.

Examples include:

• Authentication failures

• Permission changes

• Administrative actions

• Deployment events

Logs should support incident investigation without exposing sensitive information.

Vulnerability Management

Security vulnerabilities should be:

• Assessed promptly.

• Prioritized by severity.

• Patched through controlled releases.

• Documented when appropriate.

Known vulnerabilities should not remain unresolved without explicit business acceptance of the associated risk.

Incident Response

Every production application should have a documented process for handling security incidents.

Typical stages include:

1. Detection

2. Containment

3. Investigation

4. Recovery

5. Post-incident review

Every incident should result in actionable improvements.

Security Reviews

Security should be reviewed during:

• Architecture decisions

• Pull requests

• Deployments

• Infrastructure changes

• Major feature releases

Security review should be integrated into existing engineering workflows rather than treated as a separate activity.

Engineering Decision

Security by Design

Status: Accepted

Decision

Security is integrated into every phase of the Rundown engineering lifecycle rather than implemented as a final production checklist.

Reasoning

This approach:

• Reduces vulnerabilities.

• Improves operational resilience.

• Supports secure development practices.

• Simplifies long-term maintenance.

• Encourages consistent engineering discipline.

Security Checklist

Before production launch, verify:

• HTTPS enforced.

• Secrets managed securely.

• Least privilege applied.

• SSH secured.

• Firewall configured.

• Dependencies reviewed.

• Security headers enabled.

• Monitoring active.

• Backups verified.

• Incident response documented.

Summary

Security hardening strengthens every layer of a Rundown application through secure defaults, disciplined engineering practices, and continuous operational vigilance.

By treating security as an architectural property rather than a standalone feature, Rundown delivers systems that are resilient, maintainable, and prepared for long-term production use.

Related Documents

• 18-authentication-authorization.md

• 24-hosting-architecture.md

• 28-ci-cd-standards.md

• 29-monitoring-logging.md

• 30-backup-recovery.md

Related ADRs

• ADR-003: Documentation Information Architecture