Re-thinking Application Security for DevSecOps and Scale
Application Security (AppSec) has been around for decades, but it has fallen behind application development advancements like DevOps and cloud. How...
6 min read
Liav Caspi
:
Jul 18, 2022 7:49:58 AM
Development teams already work in a very methodical repeating process – the Software Development Lifecycle (SDLC) – and a huge opportunity exists to infuse better security within it through a combination of awareness, activities and workflows such that the outcome would be far more secure software. That is the Secure SDLC (SSDLC).
Software is eating the world, and software requires a behind-the-scenes factory that builds it. It’s hard to over stress the importance of security in software development today since applications are hacked daily with constantly changing tactics, and security and development leaders need solutions and methodologies to minimize the risks.
This blog will guide you through the implementation of a set of SSDLC methodologies aiming to incorporate security directly within the Software Development Lifecycle.
Nearly half of security breaches are rooted in code. But the other half of the attack surface posed by software is huge – APIs, open-source libraries, application infrastructure, and more. Modern development such as cloud and microservices have increased that attack surface even further, as well as growing dependencies on external software libraries and third-party components.
In the past, traditional software testing caught problems after development in dedicated testing activities. But this is now widely viewed as insufficient. It’s also an inefficient approach because:
For those reasons, it is agreed industry-wide that information security should be integrated within the development lifecycle. In other words – turning it into a Secure Software Development Lifecycle – called SSDLC or SDL (Secure Development Lifecycle) for short.
Engineers are at the heart of software creation and therefore should also be further encouraged and empowered to build it securely. It has been proven again and again that good hygiene and security practices during software development will immensely reduce the overall risk and allow your organization to ensure the integrity of every software release.
The journey for creating an SSDLC begins with a model. We will use the 5-step model commonly seen in the industry which breaks down SSDLC into 5 phases:
Traditional security testing was done on steps (4) and (5) as an activity before and after production software release. For modern software development, it is important to embed security into each of these 5 steps.
The key concept here is to set the tone and define the security aspects of the upcoming product or product feature. It is an important opportunity to drive a “security first” mindset and promote developer awareness.
For example – a new notification service is being drafted which would notify customers on important events. Security requirements should include, for example, separating tenants such that a notification will never reach the “wrong” customer. Also – will notifications ever contain sensitive data? If so, this introducing a range of security and privacy concern that must be accommodated.
The goal in this phase should be to create a “threat model” that will be used during the entire development lifecycle of the product or feature. This model should be based on security best practices, such as the one that OWASP defines.
The threat model should be the basis of its own requirements sessions. A good recommended first step is to schedule such a requirements session using a generic threat model as a template. Within that meeting – define the principles and guidelines to be used during development and testing – what is key to secure? What are the security best practices? It should also define all security controls that should be implemented as part of the development lifecycle.
Another option to consider – require a threat modeling and design meeting prior to scheduling a feature to be part of the sprint and explicitly define who can approve the threat model.
Usually, engineering teams create the technical design of a feature. In our notification service example, there might be a new microservice, a message queue, a database to store undelivered notifications, etc. In this phase you must verify that the security design addresses the threat model generated in the requirements phase.
This is where security mechanisms are defined within the design. Key steps include:
Development teams will ask for prioritization, and it is essential to come up with the absolutely non-acceptable risk, and the list of items where the risk can be accepted or reduced later.
Embedding security into coding means developers write safe code, eliminate security risks while coding, and do this before they submit their final version for further testing and deployment. To do this, several things need to be considered:
This phase is a bit tricky. Having a true agile SDLC means there is no linear process where everything stops and only testing occurs. Most teams today build some sort of CI/CD pipeline where Continuous Integration occurs, and software is constantly tested.
In this model, there are a series of tests occurring at multiple stages. Some during coding, some after every code submission, some nightly, and some testing the live production environment.
Within the requirement stage, it is important to map where security tests should run. Previously we mentioned tests during the coding phase. But it is possible to introduce additional tests before deployment – it all depends on your release strategy.
To sum up, two key areas are important for this phase:
There are many other security testing tools available that we didn’t cover in this short blog. To see a comparison of all available security tools and techniques, visit this page.
In this phase, it is all about having a response plan and being one step ahead of attacks. You need to build the processes that allow you to A) be alerted if a new external risk becomes known, and B) stay on top of emerging security attacks, trends and solutions.
It is time for everyone to hop on the SSDLC wagon. Two colliding trends require this call to action: the first is the growing threat of security breaches, and the second is the modernization of the application development lifecycle.
To have an effective security program, you must start implementing security in EVERY step of the SDLC, not just at the end of it. Fortunately, there is a lot of knowledge available to help, and several easy-to-use and cost-effective actions you can take to get started. And the advantages of implementing an SSDLC are worth it. By doing so you can achieve benefits such as a comprehensive view of your SDLC, the ability to continuously monitor your security posture, and gain valuable context and business critical insights on applications from code-to-cloud.
Remember that it will be an incremental process and that every step along the way will be beneficial. One effective approach to start or boost you secure SDLC, is to have a complete mapping of your development environment – all assets, users, scanners and automations. Legit Security helps with consolidating this inventory and getting actionable insights to solidify security across your broader SSDLC environment.
If you'd like to see a complete map of your SDLC and start your journey toward an SSDLC, request a demo of the Legit Security Platform today!
Join the Legit Security Newsletter to stay up-to-date on the latest tips, tricks, and tech-industry news.
Application Security (AppSec) has been around for decades, but it has fallen behind application development advancements like DevOps and cloud. How...
I'm excited to share that Legit Security is officially launching out of stealth mode. While in stealth, we’ve been incredibly busy acquiring our...
Once upon a time in Application Security, times were simpler. Not long ago security and development teams could simply scan their code for...