Embedding Security into Software Development Life Cycle

How to build the most secure software?

The answer lies in how seamlessly security is embedded into Software Development Life Cycle (SDLC).

Let’s imagine a situation where company hires talented engineers to expand its online business and builds the software with the best available technologies. A few days after the software goes live the media reports there was a serious data breach. Hackers have stolen customer details including payment card details which may cause heavy financial and reputation loss to the company. The engineering team starts detailed analysis and finds that attackers exploited a flaw in implementing user authentication and were able to steal the data. The team also discovers that customer data was encrypted; however, the encrypted cryptographic keys were not secured. So, everybody starts wondering where things went wrong. Further analysis reveals that user authentication flaw was due to poor design. Cryptographic keys got exposed due to incorrect deployment and secrets management strategies. Though the scenario mentioned is hypothetical, but threats are real.

Let’s revisit the idea of embedding security into SDLC. Below diagram highlights various phases of SDLC with each phase mapped to security activities.

SDLC Cycle with Integrated Security in each phase

Before we dig into security part of SDLC, let us recollect what activities does SDLC consists of? Below picture summarizes the SDLC process in brief.

SDLC Stages

Security is an important part of any software but often neglected during software development process. Organizations should create a secure SDLC process where security is incorporated naturally into each phase of SDLC. This can be achieved by adding security checkpoints at each phase and making sure security is part of each phase of SDLC. Creating a secure SDLC process needs dedicated effort and spending from the organizations but yields high ROI (Return on Investment) in long run. Advantage is that the software thus developed would be free from serious security threats and vulnerabilities. It is far less likely to have potential attack vectors, helping organizations to save time, effort and most importantly to guard customers trust in the business.

Embedding security into SDLC through automation is a better approach rather than manual processes for security. Automation makes sure, security becomes part of SDLC, seamlessly. It helps in introducing security governance process which can enforce developers to implement security as part of software development. The goal of secure SDLC should be to limit vulnerabilities in deployed software.

Let’s revisit each phase and see what security tools or approach can be used to integrate security process into SDLC.

Requirements Gathering & Analysis phase: Security should be considered during requirements gathering phase. Is the software resilient from security attacks? How quickly software can recover in case of security incidence? What check points and security techniques can guard the software against attackers without creating much hassle for genuine users? The answers to these kind of questions leads towards defining security requirements at initial stage.

The requirements document should have mandatory section about security requirements. This section enforces customers and stakeholders to start thinking about security at very early stage in SDLC process rather than having security as an afterthought.

Design phase: Most vulnerabilities discovered in software are caused by poor design, incorrect technologies chosen, and less attention being given to security during Design phase.

Threat Modeling is an important process to design secure systems. It is based on identifying threats in order to develop mitigations to them. In an ideal scenario, threat modeling should be done as soon as software architecture is in place. Earlier the potential attacks are identified, the more time and cost-efficient solutions can be designed. But not all scenarios are ideal and not all software undergoes threat modeling assessment during design phase. Threat modeling can be done in later stages as well, which can still uncover potential flaws in the system. There are number of tools available which can help in performing threat modeling.

Implementation phase: During implementation phase, technology specific security guidelines and security code reviews should be the focus. Tools that automate security scanning of code are called security code analysis tools, also referred as Static Application Security Testing (SAST) tools. SAST tools perform automated security code review. Inspects and analyzes an application code to discover security vulnerabilities without actually executing code.

The software applications are built upon open-source code and libraries. The developers are not only accountable for the code they write but also responsible for choosing open-source and third-party libraries which are secure and free from vulnerabilities. Software Composition Analysis (SCA) tools helps developers to mitigate security vulnerabilities in open-source and third-party libraries, container images and registries. SCA tools can also scan open-source license compliance data and provide relevant suggestions. Organizations can define acceptable security baseline like approved base images, operating systems and base security configurations. The secure baseline components make sure the same vulnerabilities are not proliferated to multiple products in organizations.

The SAST and SCA tools can be integrated into CICD (Continuous Integration and Continuous Deployment) pipeline to make sure security vulnerabilities are addressed in earlier phases of SDLC. The organizations can thus apply enforcement policies to address security issues before the software gets into testing and deployment phases.

Testing phase: During testing phase, the developers and testers can examine application software for security vulnerabilities. There are various techniques to perform security testing during this phase.

  • Penetration Testing (Pen Testing): The testers examine the application, network or computer system to find vulnerabilities that an attacker could exploit. This can be a manual process or can be a combination of manual testing along with the usage of Dynamic Application Security Testing (DAST) tools. DAST tools can help to automate this testing but can also produce false positives results that are not exploitable, hence may still need developers or testers to confirm each of the findings.
  • Fuzz Testing: The vulnerabilities are found by sending intentionally malformed inputs to the application. Fuzzing tools can automate this process by creating malformed inputs, delivering that inputs to the target software and detecting the application failures.
  • Interactive Application Security Testing (IAST): Combines SAST, DAST with runtime component which can be interwoven into applications runtime (E.g., into the server side JVM). IAST tools analyzes code for security vulnerabilities while application is run by automated test or human tester. IAST works better when deployed in test environment with automated functional test running.

Some of the most popular SAST/DAST tools and their comparison can be found here.

Deployment phase: Deployment phase can play a crucial role in strengthening the security posture of the software. Deployment over cloud environments brings additional challenges from security point of view. The application config parameters like database parameters, private certificates or any kind of deployment related sensitive config parameters should always be stored in secrets management tools like key vaults made available to applications during run time. Cloud environments use deployment configurations a code. Container environments uses images which can have security vulnerabilities. There are security tools which can scan deployment config files and container images for any vulnerabilities, malwares and sensitive data. Such tools should be configured as part of CI/CD pipelines which can scan and automatically block deployments which could be risky from security point of view.

Operations & Maintenance: Post release activities involves security engineers performs security monitoring, security testing, incident response etc. Continuous monitoring, analyzing security events, correlating certain events with security threats and take actions to mitigate risks. There are security scan tools to scan the applications or networks for vulnerabilities. These tools are capable of performing continuous security scans and notify if any threats found. Here are few examples of such security scanners. It should be noted that security scanners should be used in an ethical way. Never use these scanners without the permission of infrastructure and application owners.

The weakest link in chain of security are humans. We can extend that statement as; developers might become weakest link in security of SDLC. Hence, it’s of utmost importance to have security awareness and training programs for developers at regular intervals. Forewarned developers are forearmed developers.

Conclusion: Adopting security into SDLC is the need of the hour. Data breaches can lead to damaged market reputation, declining stock value, weak customer relationship and decreased sales. Embedding security into each phase of SDLC prevents most security vulnerabilities in a timely manner, protecting an organization from several cyber-attacks.

If you would like to read further, check out this, secure SDLC practices, by Microsoft.

Acknowledgements: I would like to thank my colleagues, Eric Goldman, Murali Segu, Oscar Blass and Sureshkumar Thangavel for reading this blog carefully and suggesting improvements.

Embedding Security into Software Development Life Cycle was originally published in Walmart Global Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Article Link: https://medium.com/walmartglobaltech/embedding-security-into-software-development-life-cycle-9084169ebbc7?source=rss----905ea2b3d4d1---4