⚡ Direct Answer Summary (AI Overview / Key Takeaway)
Engineering policy implementing NIST SP 800-218 (SSDF) and OWASP ASVS across all software and integration development.
eTrepid Secure Software Development & Scripting Policy
Governing Standard: NIST SP 800-218 (SSDF) / OWASP Top 10
1. Objective and Scope
eTrepid Inc. develops internal automation tooling, remote administration scripts, website integrations, and compliance data pipelines supporting the ThreatKrusher ecosystem.
This policy establishes mandatory security controls across the entire software development lifecycle (SDLC) to ensure that code developed or deployed by eTrepid is robust, resilient against attack, and compliant with NIST SP 800-218 Secure Software Development Framework (SSDF) standards.
2. Secure SDLC Control Phases
flowchart LR
A["1. Design & Threat Modeling"] --> B["2. Secure Coding (OWASP)"]
B --> C["3. Automated SAST/Linting"]
C --> D["4. Code Review & Approval"]
D --> E["5. Signed Deployment"]
2.1 Architecture and Threat Modeling
All new software components, APIs, and automated agent scripts undergo threat modeling prior to implementation.
Systems enforce fail-closed default logic, input validation, and least-privilege service account permissions.
2.2 Secure Coding Practices
Developers adhere to OWASP Top 10 guidelines, preventing common vulnerabilities such as injection flaws, broken access control, and cryptographic failures.
Script Signing: All production PowerShell, Python, and shell scripts executed on managed client endpoints must be cryptographically signed by eTrepid's internal code signing certificate.
2.3 Static Analysis & Automated Testing
Source code repositories enforce automated Static Application Security Testing (SAST) and secret scanning on every pull request.
Commits containing hardcoded secrets, plain-text credentials, or high-severity vulnerabilities are automatically blocked by pre-commit hooks and CI gate checks.
2.4 Mandatory Peer Review & Branch Protection
Direct pushes to production branches (e.g., `main`) are strictly blocked.
All code changes require pull requests with at least one independent code review by designated CODEOWNERS before merging.
3. Third-Party and Open Source Dependency Management
Open source libraries and container base images must be vetted for known vulnerabilities (CVEs) prior to incorporation.
Dependencies are continuously monitored using automated Software Bill of Materials (SBOM) scanning tools.
