All software developers know how to code, but that doesn’t mean they all fully understand how to code securely. This piece outlines the most fundamental secure software development activities and provides actionable guidance to improve secure coding practices.
Software Development Security Process
We suggest integrating a series of security activities directly into your existing software development processes. Irrespective of how you currently build your software – traditional waterfall or modern DevOps and continuous integration/continuous
development (CI/CD) – you can enhance your existing practices with a carefully selected set of security activities.
Specifically, all software development activities tend to include, to one degree or another, a set of actions descended from the early waterfall methodologies of the 1970s and 1980s. At a minimum, these include:
- Design
- Implementation
- Testing
- Deployment
- Operations
Each of those processes can be further broken down into its core components, but from a top-level viewpoint, they comprise the fundamentals.
Today’s agile methodologies such as DevOps employ many of these same processes, but the ordering of events varies to resemble spiral and rapid prototype software engineering processes more closely. Further, agile seeks to empower software developers
themselves to perform much of the heavy lifting formerly done by security staff and others. It also focuses on re-using software components that have gone through rigorous vetting processes already to leverage those efforts over and over. All these
things are to be commended and can be thoroughly leveraged in building a set of secure development activities in an agile environment.
For each of the process steps above, one or more security activities can enhance the overall security of the end product.
READ: How to Hire and Retain Cybersecurity Talent
1. Threat Model at the Design Stage
Threat modeling is a process in which a software product’s design is reviewed critically for potential – and often disastrous – security design defects. A good threat model can also provide vital navigational inputs to the security process
by spotlighting areas of the software that warrant extra scrutiny in code reviews and/or testing. As such, a threat model done early and updated often during the development process should be considered a vital aspect of software development.
While available tools to support threat modeling are scant, a whiteboard and a capable team of participants can prove more than adequate. Teams should consider:
- Assigning a leader: Generally, a threat model is led by a senior software developer or a security team member.
- Inventorying/understanding the components: The fundamental process is to gather a thorough inventory of all the software components of a system and learn all the details about how the software functions in its entirety, starting with its invocation through
its full production state, and onward to shut down.
- Assessing each component’s security: Once a comprehensive understanding of how the software runs is gathered, each component should be assessed for its security attributes. These should include data input/output validation, protecting secrets both
in transit and at rest, component identification and authentication, access controls and so forth.
Particularly in agile methodologies, the notion of a “design” may well be an ever evolving and changing thing. That is to be expected and is entirely supportable through threat modeling. Whenever material changes are made to a design, the
threat model should be re-visited to ensure it addresses any corresponding changes there. This is true irrespective of how formally or informally the actual design architecture is collected. Even a whiteboard or back-of-the-napkin view of an application’s
architecture can be helpful.
2. Template and Review the Implementation
The coding process should follow existing secure code patterns and templates, and the resulting code should be reviewed for compliance as well as potential security defects. Teams should consider:
- Developing a set of standardized code patterns that implement each major security control: These should cover the basics, such as identification and authentication, access control, session management, data input validation, data output encoding, network
connections, server-to-server connections, and database access.
- Conducting peer reviews: Periodic peer reviews can be effective at verifying compliance against those code standards. For optimal results, consider conducting these frequently in small teams.
- Defending and justifying non-compliant code: When a non-compliant implementation of any of the above security controls is found, the developer should defend and justify the code. If approved, that code can be considered for addition to the standard library.
- Performing code reviews: Code reviews using static analysis security testing (SAST) tools can be implemented for each code commit into the team’s source code repository of choice. Further, the threat model should be used to guide the code reviews
to the areas of highest business risk. Those code blocks should be reviewed with a high degree of rigor.
READ: How to Develop a Cybersecurity Training Program
3. Test for Security Defects
From a unit level all the way up to the full software complement, software should be rigorously tested for security defects. This should include risk-driven testing of specific security-critical features (e.g., appropriate encryption for payment card
information) up to testing for well-known coding defects (e.g., cross-site scripting, SQL injection). Teams should consider:
- Testing iteratively: Security testing an application should be done throughout the development process.
- Testing individual code segments during unit testing. These should include API fuzzing, data input and output validation, and so forth.
- Performing risk-based testing of the full application: This should validate the highest risk processes uncovered in the threat model.
- Scanning for known vulnerabilities using tools such as SAST, dynamic application security testing (DAST) and software composition analysis (SCA).
4. Check the Deployment for Misconfigurations
During deployment, additional tests and validation steps should be performed. These steps might include:
- SCA to look for known vulnerabilities in any of the closed- or open-source components used to build the software.
- Configuration: All containers and servers should be configured using robust secure configuration practices.
5. Operate the Software Securely Over Time
Once deployed, the security of a software system should be maintained just as its configuration is. Threat intelligence should be seeking information about defects in all the software components, as well as for actionable indicators of compromise (IoCs)
gathered from incident response operations internally and within the industry.
During ongoing operation and maintenance, it is important to make use of threat intelligence to keep up to date with ever evolving threats and attack techniques. Periodic vulnerability scanning for known vulnerabilities is a great starting point, along
with periodically revisiting the application’s component inventory and reviewing it for newly discovered vulnerabilities, patches, updates, etc.
Secure Software Development Tips
While everything listed within the five steps above can seem overwhelming, there is no problem with implementing these processes iteratively and growing maturity over time. To improve your chances of success, consider:
- Planning a roadmap for implementing software security practices into the existing development process.
- Performing a threat model on existing software system(s).
- Developing an internal library of standard security controls as described above.
- Reviewing and integrating tools into the code review and testing processes to the extent feasible.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in
connection with such information, opinions, or advice.