<< All versions
Skill v1.0.1
currentAutomated scan100/100redhatproductsecurity/prodsec-skills/secure-by-design
+2 new
──Details
PublishedAugust 1, 2026 at 06:06 PM
Content Hashsha256:3ff49538c18e4191...
Git SHAb55c6b9c3392
Bump Typepatch
──Files
Files (1 file, 3.3 KB)
SKILL.md3.3 KBactive
SKILL.md · 74 lines · 3.3 KB
version: "1.0.1" name: secure-by-design description: > Apply Secure by Design, by Default, and in Deployment (SD3) principles. Use when reviewing default configurations, setup processes, update mechanisms, or evaluating whether a system fails open or closed. metadata: category: secure_development subcategory: security-principles
Secure by Design, by Default, in Deployment (SD3)
Principle: The default settings of a system or application are configured with strong security measures in place. Systems should be configured in a least-privilege model so that no unnecessary services, daemons, or accounts are enabled.
Secure Default Configurations
- Ship products with secure defaults that protect users without requiring manual hardening
- Generate unique keys and secrets during first run or installation, not at build time
- Encourage users to review and customize settings, but ensure the uncustomized state is safe
- Minimizes risk from users or administrators who overlook or delay security configuration
Fail Secure
- Design services to fail closed: when they fail, they deny access rather than granting it
- A security service that cannot be reached must result in a denied request, not an open door
- Apply this to authentication, authorization, input validation, and configuration loading
Secure Baselines
- Create server and application security baselines as reference configurations
- Deploy new systems from these baselines to ensure consistency
- Systems adhering to baselines are less vulnerable and require less ongoing maintenance
Encryption and Authentication by Default
- Enable encryption (TLS) and authentication by default, not as opt-in features
- Use HTTPS as the default communication protocol
- Protect data in transit and at rest as a baseline, not an upgrade
No Hardcoded Credentials
- Never use hard-coded secrets, default passwords, or static account credentials in code
- Generate unique credentials at deployment time
- Use secrets management systems (Vault, AWS Secrets Manager, etc.)
Default Deny Policies
- Only explicitly allowed actions are permitted
- No unnecessary services, daemons, or network ports are enabled
- Default network policies deny all traffic; allow rules are added explicitly
Code Integrity and Updates
- Use digital signatures and cryptographic hashes to verify the integrity and authenticity of software updates
- Implement automated update mechanisms to reduce the window of vulnerability
- Test patches thoroughly before deployment
- Secure the update infrastructure itself with access controls and monitoring
Implementation Checklist
- [ ] Default configuration is secure without manual hardening
- [ ] Unique secrets are generated at first run or installation (not hardcoded)
- [ ] Service failures result in denied access (fail closed), not open access
- [ ] TLS and authentication are enabled by default
- [ ] HTTPS is the default protocol for all communication
- [ ] No hardcoded credentials exist in the codebase
- [ ] Default network policies deny all traffic; allow rules are explicit
- [ ] Unnecessary services, ports, and accounts are disabled by default
- [ ] Software updates are signed and verified before installation
- [ ] Update infrastructure is secured with access controls and monitoring
- [ ] Security baselines exist and new deployments are built from them