Securing the SDLC

Guide to help you design a secure Software Development Lifecycle

Many security professionals might come across this task in their carrier to develop a secure SDLC framework for their organizations. Having years of experience in different areas in security field makes you feel that everything around it is extremely important, and nothing can be missed out. Infact that's absolutely true, however when one is asked to design a secure Software Development Lifecycle for their company it becomes absolutely important to keep the document crisp and in the correct order in which it can make best sense. Because believe it or not, no one likes reading lengthy documents specially developers as its time consuming and knowledge absorption rate reduces over time. In this blog, I have tried to summarize the important areas that you should focus when it comes to building security in the SDLC.

Before we start discussing in-depth of securing things lets first understand the phases of SDLC which the below image summarizes.

Always start designing the Secure SDLC keeping in mind that it will be useful for anyone who can influence application security like product owners, project managers, developers, release management, operations etc. It is important that you consider security frameworks like NIST, OWASP, SANS to design with efficiency.

After understanding the phases of SDLC, lets identify what steps should we introduce to bring in security.

In this phase, we try to understand the application portfolio. Once you understand the type of application, features, types of user base, technologies etc perform threat modelling and risk assessment. You can perform a user risk analysis and document the findings. You might also want to invest sometime in understanding whether any third-party components are involved in order to understand the risks around it. This could be a good phase to identify security champions (personnels who could be from different field like frontend developers, middleware team or product owners who are keen to learn about security and would be the responsible to make sure the secure SDLC framework is being followed for their application) to provide them with trainings and making them aware of security.

2. Design Phase:

Start by understanding the architecture diagrams. Define the security requirements once an architecture review has been performed. Apply the principle of “Defense in Depth” and “Zero Trust Model” (this depends on organization needs) and design your security requirements. Listing some of the areas that you might want to focus on for setting up security requirements (not an exhaustive list):

i) Access and authorization levels in different environments like production, pre-production, staging etc.

ii) Risks from third party component (like Saas) and management around that and reviewing them.

iii) If any outsourced development activities are involved, then setting principles and boundaries around that. What kind of access levels the contractors will need and what actions are they authorized to perform. What responsibilities will they have in terms of fixing vulnerabilities, upgrading systems, patch management etc.

iv) Securing the operations — Multi factor authentication, IAM policies, authentication to hosting environments, hardening your systems (application servers, webs servers, cloud environments, containers, runtime environments, CICD pipelines, secret management and the list goes on!!

v) Encryption mechanism that needs to be applied in various areas like setting up the requirement for data at rest, data in transit etc.

vi) Data classification — based on the use cases, classification of data is mandatory to understanding what is PII, confidential or sensitive data. Making sure that data privacy is in consideration all the times based on the regions/countries the data is residing or processed.

3. Deploy:

You must understand the steps that are being followed to deploy an application. There will be brainstorming needed to secure your deployment pipelines (thats another huge area of discussion). You must understand the deployment steps and plan.

On another note, before a solution goes live in production there are several security assessments it is advised to undergo. It is always better to shift as much left as possible to reduce introducing security bugs at the later stages of SDLC. Some vendors like “Whitesource” even provide browser plugins for developers so that when they are downloading open-source components like libraries, frameworks etc they get notified that they are downloading a version which might have vulnerabilities. Similarly, you have IDE plugins which help you upgrade the libraries which might have vulnerabilities. Below is the list of assessment that an application team should undergo before going live in production (not all organizations mandate each step, however it is suggested as part of best practice)

i) Secure code reviews (SAST)- code reviews for identifying bugs in the solution. Some major tools that you might have heard about Checkmarx, Veracode, CodeQL, Synk etc. Certifications like OSWE majorly focus on this area as well.

ii) Static Code Analysis (SCA)\Dependency scans — It is important that open-source components are scanned for any known vulnerabilities existing in the code. Some tools that you might have heard about which provides you with this feature — Dependabot alerts by Github, JFrog, Synk, Whitesource, Blackduck, Debricked and Sontype. All these tools provide a wide variety of other features too along with dependency reviews.

iv) Secret Scanning — sometimes secrets are unintentionally left in the code which might lead to secret leaks and compromises. It is always advised to scan for secrets in your code in addition to SAST.

v) Penetration testing- It is always important to get a thorough pentest conducted to cover all grounds for the applications. Aside from the usual testcase that covers OWASP Top 10, SANS 25 or standards like PCI-DSS etc you might also want to design testcases on some specific areas like around the cloud environment, secret management, clusters, infrastructure etc

4. Maintenance:

You must ensure to continuously monitor the applications by enabling proper logging and integration with your SIEM tools. You must have incident management and proper Business Continuity Plans(BCP) in place in case when the application goes down. Change management, configuration management and security reviews must be conducted continuously. Set proper decommissioning policies in place for when the time comes to sunset a solution.

One must remember that every organization has different portfolios and product catalogues which shifts focus areas. Like for example, your organization might be completely outsourcing all the code development so in that case you might have to have a better focus around setting up policies for the contractors. Or some organization might want to focus more on their usage of allowed and restricted licenses, so the focus areas change accordingly. Some might say we are new to cloud setup and Kubernetes environment (hypothetically) and so they might want to spend more time on setting up policies around that to avoid any security gaps there. However, setting up a bare minimum requirement covering all grounds helps you enforce security from the very beginning of the lifecycle.

I might have missed some points which you may feel is essential to have in a secure SLDC document. What I have tried to do is cover grounds holistically and not detail out areas in lengths. I hope this blog helps and gives you a starting point for setting up a secure Software Development Lifecycle for your organization.

References

Related posts:

Thanks for checking out a bit of my work. I’ve added commentary to some of these pieces for context. Let me know what you think! The following is web copy for a non-profit organization. I also…

Datastream is a serverless and easy-to-use change data capture (CDC) and replication service. It allows you to synchronize data across heterogeneous databases and applications reliably, and with…

In order for something to be considered news, it must adhere to one or more of five qualities. These elements of newsworthiness are proximity, significance, timeliness, prominence, and human…