Watch Andor on Disney+ and pay close attention to how Luthen Rael runs the Rebellion. He does not wing it. Every cell has defined procedures, defined limits, and defined checks. Security is not something he layers on after the operation is planned. It is built into how every mission runs from the first conversation. Your software development process should work exactly the same way.
What Is Establish and Maintain a Secure Application Development Process?
It means security is part of how you build software, not something you bolt on after the code is written. You define security requirements before the first line of code appears. You design with security in mind. You code with it in mind. You test for it before you ship.
The official CIS guidance puts it this way: "Establish and maintain a secure application development process. In the process, address such items as: an application security requirements process, secure design, secure coding practices, application security testing procedures (such as static testing, dynamic testing, fuzzing, and penetration testing), and application security training for all staff involved in software development."
Why It Matters
Most application vulnerabilities are not exotic. They are the predictable result of skipping security steps during development. SQL injection, insecure deserialization, broken authentication: these are not mysteries. They are gaps in process.
When security is absent from your development lifecycle, your only defense is finding problems after the software ships. That is expensive, slow, and often public. A secure development process catches issues early, when a fix costs a fraction of what it costs in production.
This safeguard also has compliance implications. SOC 2, PCI DSS, and ISO 27001 all expect documented secure development practices. If you do not have them, that absence is a finding waiting to be written up.
Key Details or How It Works
- Security requirements are defined at project kickoff, alongside functional requirements, not as an afterthought during QA.
- Secure design includes threat modeling: asking what could go wrong before writing a single line of code.
- Secure coding practices cover input validation, error handling, secrets management, and the use of vetted libraries and frameworks.
- Static application security testing (SAST) analyzes code without executing it and catches issues like injection flaws and hard-coded credentials.
- Dynamic application security testing (DAST) runs the application and probes it for weaknesses in a live environment.
- Fuzzing sends malformed or unexpected inputs to find crashes and edge cases that structured testing routinely misses.
- Penetration testing applies an adversary mindset to the finished application before attackers get the chance to do the same.
How to Implement Establish and Maintain a Secure Application Development Process
- Document your secure development process. Write it down, put it in version control, and make it the official standard for all development work, whether the work is done in-house or by a third party.
- Define security requirements at project kickoff. Use a checklist or a framework like OWASP ASVS to ensure that authentication, authorization, data protection, and input handling are addressed before design begins.
- Conduct threat modeling during the design phase. Use a lightweight method like STRIDE or PASTA to identify what an attacker would target and build defenses into the architecture before any code is written.
- Integrate automated security testing into your CI/CD pipeline. Static analysis should run on every commit. Dynamic testing should run against every build deployed to staging. Automate it so developers get fast feedback without a separate security review queue slowing them down.
- Establish a training cadence for developers. Secure coding training is not a one-time checkbox. Annual refreshers tied to current threat patterns keep skills current and reinforce the expectation that security is every developer's responsibility, not just the security team's.
- Review and update the process at least annually. Threats evolve. Frameworks evolve. Your documented process should evolve with them.
Final Thoughts
Luthen Rael did not build the Rebellion by hoping operatives would figure out security on their own. He built a structure, defined the rules, and made security the default rather than the afterthought. Your development team does not need a Rebellion. But it does need a process. Build it deliberately, maintain it consistently, and your applications will be significantly harder to compromise before they ever reach production.
Resources
Here is a link to the Policy Templates provided free of charge from the fine folks at the Center for Internet Security.
Looking for even more detail? Here you go. If this still does not satisfy your curiosity, DM me.
Official CIS Text
CIS Control 16: Application Software Security Manage the security life cycle of in-house developed, hosted, or acquired software to prevent, detect, and remediate security weaknesses before they can impact the enterprise.
CIS Safeguard 16.1: Establish and Maintain a Secure Application Development Process Establish and maintain a secure application development process. In the process, address such items as: an application security requirements process, secure design, secure coding practices, application security testing procedures (such as static testing, dynamic testing, fuzzing, and penetration testing), and application security training for all staff involved in software development.
Shameless Marketing Information
Gotham Technology Group helps organizations design and mature secure application development programs, from threat modeling and developer training to full DevSecOps pipeline integration. If your development process does not yet include security by design, we can help you build one that does.