Requirement
Essential Cybersecurity Controls (ECC – 2 : 2024) - Control - 1-6-3 – The cybersecurity requirements related to software and application development projects must include at least the following:
Understanding the Requirement
This control expects that every software and application development project formally captures and enforces cybersecurity requirements mapped to the listed objectives (1-6-3-1 through 1-6-3-5). In practical terms, that means defining security requirements up front, embedding secure design and coding practices into the development lifecycle, requiring testing and verification (including vulnerability and dependency checks), managing changes and releases with security gates, and keeping clear documentation of decisions, dependencies, and approval records so security is repeatable and auditable.
Technical Implementation
- Define a lightweight Secure SDLC checklist: Create a one-page checklist that maps to objectives 1-6-3-1 → 1-6-3-5 (requirements, design, coding, testing, change/release). Require a completed checklist as part of any new project kickoff and as a gating artifact before production deploys.
- Threat modeling and security requirements at kickoff: For each feature or project, run a 30–60 minute threat-modeling session (developer + product + one security champion). Produce explicit security requirements (authentication, authorization, input validation, data handling, logging, and compliance needs) and record them in the ticket or requirements doc.
- Automate static and dependency scanning in CI: Integrate an open-source or commercial SAST tool and dependency vulnerability scanner into your CI pipeline so every pull request runs automated scans. Block merges on high/critical findings until triaged and fixed or mitigated with documented risk acceptance.
- Peer review + security-focused code review: Enforce mandatory peer reviews and add a short security review checklist for reviewers (e.g., secrets, crypto misuse, input validation, access checks). Use pre-merge checks for secrets scanning and linting to reduce common mistakes.
- Pre-production security testing and release gates: Require DAST or manual penetration test for externally facing services and run integration tests that exercise auth flows and error handling. Use a release approval step requiring signoff from the dev lead and the security champion for production deployments.
- Dependency management and SBOM practice: Maintain a software bill of materials (SBOM) for each release (even a basic one) and schedule weekly or biweekly scans for new CVEs. Assign owners for third-party components and include a documented update/patch cadence and rollback plan.
Example in a Small or Medium Business
Acme Health Apps is a 25-person SMB building a patient scheduling web service. When they adopted Control 1-6-3, the engineering manager created a one-page Secure SDLC checklist mapped to the five objectives and made it required for all project kickoffs. For a new appointment feature, the product owner, a developer, and the security champion spent 45 minutes threat-modeling and documented specific requirements: OAuth for user sessions, limits on data exposure, and logging sensitive actions. Developers added SAST and dependency scanning to their GitHub Actions pipeline so every pull request runs automated checks; PRs with critical results are blocked. Peer reviewers use a brief security checklist and run a quick secrets scan before approving. Before the feature went live, QA executed integration tests that exercised auth flows and the team produced a small SBOM and release notes. The release gate required signoff from the security champion and the engineering lead; after deployment they monitored logs and scheduled one-week follow-ups to verify no regressions or new findings. This practical, repeatable process reduced late discoveries of vulnerabilities, gave the product team confidence to ship safely, and created an auditable trail to show compliance.
Summary
Meeting Control 1-6-3 is a combination of policy and practical engineering tasks: adopt a clear Secure SDLC checklist, capture security requirements early, embed automated scanning and peer security reviews into CI/CD, enforce pre-production testing and release gates, and manage third-party dependencies with an SBOM and update cadence. For SMBs these steps are cost-effective, scalable, and create a repeatable record showing that security was considered at every stage of development—reducing risk and making compliance demonstrable without heavy overhead.
