Embedding Security Into Development: It’s as Easy as SSDLC
The saying goes: Mention security to a group of developers and they’ll run away. While that may have been true in the early days of software development, mindsets have shifted. The developers I work with realize security is a necessary part of the job, and as software development becomes an increasingly interdependent function, it can no longer stay isolated within the company.
But why should developers care about security? Because even a simple vulnerability, like a misconfiguration, can expose an organization’s data and lead to a data breach. An analysis by Imperva Threat Research finds that, on average, the number of data breaches each year is growing at a rate of 30%. Data breaches from open public cloud services are trending higher as more companies migrate operations and workloads to the cloud.
The burden of protecting an organization’s applications, APIs and sensitive data is now a shared responsibility. Developers have to take ownership for their code base and run testing to ensure it’s secure. It’s why many development teams are embracing the secure software development life cycle (SSDLC) approach.
Every professional developer needs to be proactive about security and incorporate it into their development life cycle. This doesn’t mean that developers need to acquire a Certified Information Systems Security Professional (CISSP) certification. But every developer should use the SSDLC approach for their code releases as a means for protecting from failures and improving development skills.
Secure Software Development: Understanding the Benefits and the Basics
Every step of the development process — regardless of whether you follow the agile, iterative or even waterfall approach — should be influenced by SSDLC.
A healthy SSDLC approach encourages developers to test and identify potential issues during the requirements and development phases as they are discovered. This helps clean the code base before the final code review, and before it’s pushed into development.
While there are old-school developers who may argue that embedding security slows down development or gets in the way of innovation, that’s simply not true. Not only is SSDLC more efficient, but it can also save your developers hours of work and ensure on-time delivery. Secure code minimizes the risk of compromise or exploits and reduces the chance of an unpleasant surprise once the code is in production. The SSDLC approach allows developers to focus on the next sprint versus rewriting their code if the function or application is compromised.
4 Things to Remember Before Implementing SSDLC
-
Understand security needs during the requirement stage
Before embarking on any software development project, start by understanding what needs to be built, calculate the potential impact of a security incident, and implement controls to mitigate that risk. Developers should understand how the app should be accessed by a client, if the software should interact or integrate with other applications, and identify scenarios that could trigger a breach.
During the requirement stage, developers and product teams must scope out these types of security controls in the same way they’d discuss what needs to be included as part of the software. It’ll be more challenging, and will require more time, to address security concerns after the product is added into development.
-
Design with security in mind
As code is written, developers must evaluate what should and should not be allowed, based on the scoped requirements determined in the design stage. This could include: what functionality should be externally-facing, how the application will be deployed, who should have access to the application and what third-party dependencies are needed.
When adding third-party components into the code base, investigate where the source code is from, whether it can be trusted and if it’s supported by the community. The use of open source code is multiplying as developers move quickly to meet tight deadlines. However, the efficiencies gained by using open source libraries make organizations more susceptible to compromise.
These blind spots lead to complex and potentially destructive software supply chain attacks, many of which can evade security detection. By following SSDLC best practices in your own development, you can mitigate potential vulnerabilities associated with the third-party dependencies added to your code base.
-
Check for stupid mistakes
While the volume of data breaches is growing at a troubling rate, human error is often the root cause of many incidents. Few hackers are truly sophisticated; they’re just taking advantage of stupid mistakes, like misconfigurations, that happen during development.
Misconfigurations rose on the list of OWASP Top 10 web application security risks in 2021. These are self-inflicted risks that can be easily addressed by mitigating calls out to unnecessary ports, updating default accounts and passwords, or limiting privileges. Further, a vulnerability can emerge as a result of failure to set secure values in the application server, framework or library settings.
When writing code, developers must also pay attention to the commands, such as calls to a library through an asterisk dot that doesn’t use an explicit declaration.
-
Make time for code reviews
During the testing phase, there are manual and automated ways to review the developer’s code. Code review is an elaborative exercise that allows for collaboration and information sharing. It’s a critical part of the secure software development life cycle.
This process surfaces deviations so the review team can assess the script for quality and security. That said, the value in code review is in partnering closely with the developer to understand what they’ve designed and how it should work in production.
For developers, it’s important to remember that security testing is an integral part of the development life cycle. I tell my developers to run unit tests to scan strings of code for potential issues as they’re developing the code and before it is delivered and pushed into production.
Secure Development: It’s a Journey, Not a Pit Stop
Implementing the “shift left” approach through a secure software development life cycle is a continuous process. It cannot be enforced by top-level management down to the development team, but rather must be adopted by the development team themselves.
Implementing SSDLC does not have to add hours of work or slow down development. It can become part of a developer’s day-to-day tasks. When security testing is embedded in the life cycle, it saves both developers and organizations time and resources. Through this behavior change, developers become more proficient and effective at understanding how the code they write can be hardened. In the long run, this means putting more secure applications into production and giving end users a product they can trust.