Secure SDLC
SSDLC
To release an application, engineers must perform security checks at some point in the development process. However, the software development life cycle (SDLC) doesn’t indicate how and when to perform these activities, and frequently, security becomes an afterthought or an inhibitor to launch. For many projects, it isn’t until the last stage of development that teams begin addressing security issues. Often these issues are tackled simultaneously, which leads to delays in project implementation and the accumulation of additional costs. Developing a high-quality application is challenging, and performing security testing under looming deadlines adds even more pressure. However, in addition to being costly and stressful, delaying security is risky—a low level of security could result in data breaches, reputation damage, and loss of customer trust. A better approach is embedding security into the software development life cycle (SDLC) by including security in the scope of developer responsibilities. This methodology is called Secure Software Development Life Cycle (Secure SDLC or SSDLC).
Secure SDLC = Methodology + Best Practices + Templates + Tools As a collection of best practices, tools, and templates, SSDLC aims not to eliminate traditional security checks—such as penetration tests, code review, and architecture analysis—but to include activities at each step of the standard SDLC to add security and speed up the development process. In this lesson, you will explore why Secure SDLC is essential to successful software development. You will discover the risks of neglecting security and examine SSDLC activities that support security in every phase of a project, which will prepare you to make recommendations for improving security on your projects.
The Risks of Poorly Secured Software
When an organization’s security is compromised, it can significantly interrupt critical services. For instance, Ireland’s publicly funded healthcare system, the Health Service Executive (HSE), was targeted in a cyberattack in May 2021. Russian hackers gained access to the HSE’s network and encrypted some data to demand a ransom. Ireland’s government refused to pay the criminals, and hospitals across the country had to cancel appointments, leaving thousands of Irish citizens without access to medical care.
In addition to interrupted services, the detrimental consequences of a security breach may include the costs of hiring law firms to defend the company against litigation, making restitution to customers whose data were compromised, or offering identity protection services. When consumer credit reporting agency Equifax was hacked in 2017, the hackers gained access to the personal data of over 147 million people—including their names, addresses, credit cards, and driver license numbers. Equifax has spent an enormous amount of money—nearly 2 billion dollars to date—on cleanup after the incident.
If critical data is stolen, organizations may also face government fines. Two major data privacy laws protect personal, business, and financial data.
GDPR
The General Data Protection Regulation (GDPR) is a regulation in the EU dealing with data protection and privacy. Companies who violate GDPR may face a fine of up to 20 million euros, or up to 4% of their annual global revenue of the last year, whichever is greater.
HIPAA
The Health Insurance Portability and Accountability Act (HIPAA) is a federal law in the United States. The purpose of HIPAA is to protect health care information for employees and customers. Based on the level of negligence, the penalties for companies in violation of HIPAA can be up to 50,000 dollars per violation, or up to 1.5 million dollars per year. Violations can also incur criminal charges that may result in jail time.
To ensure the security and quality of the SDLC, your team must employ several measures: shifting security to the beginning of development, applying security activities in each of the Secure SDLC phases, adjusting your approach to Agile to accommodate security needs, and adopting DevSecOps practices to accelerate work.
Shift-Left Security with Secure SDLC
Shift-left security means moving security to the earliest possible point in the development process. In a more traditional development approach, development starts without security, and software quality is only checked during the operations and monitoring phases. In shift-left security, teams embed security processes and tools in the CI/CD pipeline, allowing them to catch and correct vulnerabilities and bugs before they launch a product. Testing, feedback, and revisions happen regularly in the shift-left practice, making it easier and less expensive to fix issues. Review the graphic below and compare approaches by the number of security activities performed at each SDLC phase.
Secure SDLC enables shift-left security for teams by encouraging them to perform security activities before product development starts. Their work on security issues doesn’t end here—in a Secure SDLC, engineers perform security activities at every phase of software development.
Secure SDLC Phases and Activities
Secure SDLC includes the same phases as standard SDLC—training, requirements, design, software development, testing, and maintenance. The distinguishing feature of Secure SDLC is that it incorporates security-related activities in each phase, from gathering requirements to releasing the application.
Training
Core security training at the beginning of SSDLC ensures your project team knows the product’s policies and security requirements. It establishes the guidelines for software development and mitigates the risks of neglecting security issues.
Security training typically consists of:
Requirements
In this phase, your team gathers security and privacy information and establishes the product’s security requirements.
First, analyze general security and privacy-related information:
Then, collect specific requirements:
Next, have a security champion perform a security risk assessment (SRA) to calculate risks based on the information your team has already gathered. Evaluating application security rank and risk levels per asset allows you to apply relevant security requirements to a specific system, reducing the costs and time spent to implement security controls.
Finally, your team should also check compliance with standards and policies and create quality gates to establish minimum acceptable levels of security and privacy quality.
Design
In the Design phase, your team establishes design requirements to identify potential issues and make the product secure.
Security-related activities in this phase include:
Threat modeling The goal of this activity is to identify, enumerate, and prioritize potential vulnerabilities. Your team can conduct threat modeling based on SRA results, solution architecture, and an access control matrix. As a result, you get:
Data Flow Diagrams: extensions of architecture views from a security standpoint
Solution Specific Threats: actual threats with severity
Mitigations planning This activity helps your team develop a strategy for effectively mitigating the threats you identified in the previous step.
Attack surface analysis and reduction Finally, check the application itself and try to remove unnecessary API endpoints and machines. Once you complete these activities, your team can move into development with a clear understanding of how to build a secure application.
Software Development
In the Software Development phase, the writing of the program takes place. Your team should use approved tools and deprecate unsafe functions when you develop software.
Activities in this phase include:
Testing
After the code is submitted, your team must verify that it is secure in the Testing phase.
To assess the results of the Software Development phase and correspondence with plans created during the Design phase, engineers perform activities such as:
Maintenance
The release of the application doesn’t mean that your team is finished with security. When you deploy the application on the production infrastructure in the Maintenance phase, your team should be mindful of potential security issues in code. Also, keep an eye on security all the time while the software is operating.
Security-related activities to support the Release phase include:
In addition, the team may choose activities from the Testing phase to run in the production environment.
During each SSDLC phase, security activities help your team plan, create, and deploy a product in a timely, efficient, and secure manner. These activities require the work of a qualified and trustworthy team that guarantees the quality and integrity of projects.
Accelerate SSDLC with DevSecOps
To make the development process faster and more manageable, your team can adopt DevSecOps. This approach ensures that your team will constantly analyze, test, deliver, and release code according to security standards. You can utilize a typical DevSecOps architecture with version control, continuous integration, and continuous development pipelines (represented in the graphic below) for your project. In this process, static and dynamic application security testing, end-to-end automated and manual testing, software composition analysis, and analysis of scripts, patches, and dependencies ensure security.
Artifact Repository An artifact repository stores compiled source code. The latest artifacts automatically go from this repository to the QA environment.
Quality Assurance Environment There may be one QA environment for running tests or multiple environments for running tests (if separate environments are required for different types of testing).
CI/Build Server The build server, also called the continuous integration (CI) server, is a centralized environment for building project code. If the build was successful, the system automatically runs code analysis and unit tests and uploads results to the dashboard. If no severe security issues are identified, then the built artifact is transferred to the artifact repository. Otherwise, the code is sent back to a developer for uplift.
DAST/Manual Security Testing After an application is deployed in the QA environment(s), DAST scanning runs automatically, then manual security testing is performed. The results of these checks are also visible in the central dashboard. Based on the results, your team decides whether an application is ready to go for production approval or needs to be fixed first.
Version Control In this repository, developers on your team commit their code.
Production Approval At this stage, stakeholders review the central dashboard to decide whether a product can be released to production. Although there could be some minor bugs, an application shouldn’t have any severe (including security) issues.
Security Champion Security champion supports the development process on each stage and reviews the security checks results.
If your team has already implemented CI/CD, you can start embedding security activities into the existing CI/CD processes. With DevSecOps, each of your team members will be responsible for making their part of the product secure, significantly improving development speed and overall product quality.
Maintaining Secure SDLC
Once Secure SDLC is established in your team, you need to maintain this process properly. Specific methods of handling security issues and coordinated teamwork will help to support security throughout a project. With a shared responsibility across team members and a defined process of preventing, detecting, analyzing, and handling issues, your team will reach a sufficient application security level in a short time.
Prevent and Detect Security Issues
To prevent cyberattacks and detect security breaches in time, your team can use security improvement strategies. Prevention and detection strategies employ various tools to increase product security, foster an environment of continuous security improvement, and enhance Secure SDLC.
Prevention
Preventing a cyberattack is better than responding to one. If your team can prevent attackers from gaining access to the system, they won’t have the opportunity to steal sensitive data, cause damage, and cost the company money. A prevention strategy assumes that the system is built securely from the beginning, using instruments such as:
As a result, your team and company can significantly decrease the probability of a successful attack.
Detection
In recent years, cyberattacks have become more sophisticated, and a prevention strategy alone isn’t enough to safeguard software. As companies use more software and the number of vulnerabilities grows accordingly, it is increasingly difficult to prevent all security risks. A detection-based cybersecurity strategy considers security breaches as inevitable and suggests actions to minimize their impact and damage. A detection strategy helps your team quickly find and respond to security issues by employing:
By accepting that attacks pass through defenses and adding detection to your project’s security strategy, your team can make an application more resilient against attacks and save money.
No system can be 100% secure, but developers on your team can protect the most critical assets of an application with security improvement strategies embedded into Secure SDLC. A prevention strategy will help protect your system against known, commoditized attacks, while a detection strategy will minimize the threat impact and speed up remediation from sophisticated, custom threats.
Determining Security Risk Severity
While you should aim to detect the maximum number of security risks, not all of them require an immediate reaction from security specialists on your team and beyond. Eliminating every minor risk may not be cost-effective, so you need to prioritize carefully. Risk analysis helps your team estimate the impact of vulnerabilities on the business. Once you identify a potential risk on one of the Secure SDLC phases, you can use the model below to determine the severity of the threat and decide whether it’s worth eliminating right away or not. Therefore, assessing risk severity is a crucial activity to perform in every development phase.
Likelihood
Likelihood is a rough measure of how likely it is that a vulnerability will be discovered and exploited by an attacker based on the threat agent factors and the vulnerability factors in place. Threat agent factors (skill level, motive, ability, and size) estimate the likelihood of a successful attack from a group of possible attackers. Vulnerability factors (ease of detection, ease of use, awareness, and intrusion detection) estimate the likelihood of a particular vulnerability being detected and exploited.
Impact
A successful cyberattack has technical and business impacts. The measure of technical impact is how a potentially exploited vulnerability will affect an application, its data, and its functionality. Business impact is even more important than technical impact and justifies the investment in solving security problems. Although it stems from technical implications, business impact is assessed based on what is essential to your company. Predicting the business implications of successfully exploiting vulnerabilities may be difficult. In this case, a detailed description of the technical impact will help you assess the business risk.
Based on the likelihood and impact estimate, your team can identify the overall severity of a risk and categorize it as low, medium, or high.
LOW
Risk Example: A support engineer tampers with the delivery address in online store orders through the support portal. Although this scenario has a significant business impact on integrity, overall risk severity is low because this situation is “unlikely” to happen. A support engineer has a legal responsibility in front of the employer and can be easily tracked—therefore, the likelihood of tampering with data is low.
MEDIUM
Risk Example: An unauthenticated anonymous user performs a DoS attack on user profile functionality. The severity level is medium because the availability level of user profile data—and, consequently, the potential impact—is low, while the likelihood of this attack is “very likely.”
HIGH
Risk Example: An unauthenticated malicious user gets access to confidential financial data using an SQL injection attack in the username parameter on the login page. As a result of the attack, the hacker can download confidential data from the database and do significant damage to customers’ trust in the business. The probability and impact of this risk are both high, making the overall risk severity also high.
The more severe a risk is, the higher the cost an entire company may pay in the case of a security breach. To avoid detrimental consequences for your organization’s finances and reputation, mitigate high severity risks as soon as you identify them.
Calculating Risk Severity
Practice calculating the severity of a risk. Review the below scenario, complete each step, and choose the risk severity. Then click “submit.” Using the Open Web Application Security Project (OWASP) risk rating tool, calculate the overall severity of the following risk: An authenticated attacker hired by a competitor steals PII data (email, name, phone number, address). The system has an active detection system, access-control mechanisms defined around roles and privileges, and can fully trace any malicious actions. Note: When you open the tool, you’ll see that some fields are already filled in for you. Don’t change them—select the values for N/A fields only.
Organizations use this approach to estimate the severity of security risks and identify whether they are worth investing time and resources to eliminate them. This system can help your team avoid the distractions of minor risks and ensure you focus on more severe ones in each SSDLC phase. Therefore, you will be able to perform security activities more thoughtfully.
Catching and Handling Security Issues
Although thoughtfully constructed Secure SDLC helps to protect an application from many security threats, you still may encounter security issues. On top of security activities performed during particular SDLC phases, your team can implement a security issue handling process and bug bounty program to speed up bug detection and elimination through the whole SSDLC.
If your team is conducting a vulnerability assessment and thorough penetration testing and getting few results, implementing a bug bounty program can be an effective next step.
A bug bounty program entails having an appropriately sized and well-managed group of external users who search for and identify additional vulnerabilities. While this kind of program can be effective, it’s vital to manage the program carefully. For example, participation in the program should not violate any security policies. Moreover, any recognition or reward for identified security defects should correspond with the impact on business. Note that a bug bounty program is only a good choice if the system your team is testing is not overly sensitive (e.g., source code reviews, private networks).
To constantly identify vulnerabilities and minimize the window of opportunity for attackers, your team can establish Continuous Vulnerability Management. This process includes tracking issues and handling them according to a Service-Level Agreement (SLA).
Issue Tracking
Project teams typically use a bug tracking system (e.g., Jira) to check up-to-date security statuses and respond to possible breaches more effectively.
Service Level Agreement
Your team must mitigate security issues in a reasonable amount of time to minimize the possibility of a breach and be compliant with security standards. To establish a straightforward and fast process for handling security issues, you can utilize a Service-Level Agreement (SLA).
An SLA defines the:
Level of service expected by a customer
Reaction time
Metrics used to measure a service
Remedies or penalties for inappropriate service
As a result of these activities, you will be able to maintain an appropriate application security level long after its release.
RACI
The whole team’s responsibility for secure software development means that each team member oversees specific security activities. To avoid confusion and make the roles clear for all project members, your team can use a RACI matrix. RACI is an acronym derived from four typical project responsibilities: responsible, accountable, consulted, and informed. In SSDLC, the RACI matrix helps teams determine the roles and responsibilities for project security activities. The table below represents how to split responsibility for security activities among product and security team members.
R-responsible
A-accountable
C-consulted
I-informed
Security Awareness Trainings
I
R
R
R
R
I,C
Security Requirments, Risks
A
R,C
R
I
R
I
I,C
Threat Modeling
I,C
I,C
A,R
I,C
R
I
I,C
I,C
Secure Development
R
A,R
R
I,C
Security Tests
I,C
I,C
A,R
R
R
I,C
Cybersecurity Maturity Models
An excellent way to determine if your team’s SSDLC needs improvement is to measure the project’s security maturity. You can accomplish this by using a cybersecurity maturity model.
You can use this tool to identify strengths and opportunities and measure where the company currently resides and where it needs to be to remain secure. In addition, maturity models help your team:
Identify opportunities for enhancing security
Evaluate your current level
Take steps to bring security to the next level
The most widely used maturity models are the Building Security in Maturity Model (BSIMM), the Software Assurance Maturity Model (SAMM), and the Security Development Lifecycle (SDL).
BSIMM
Building Security in Maturity Model (BSIMM) is a study of existing software security initiatives across various industries. By providing a model of security activities that different companies implement, BSIMM lets you identify the common standards as well as unique practices in SSDLC.
SAMM
The Software Assurance Maturity Model (SAMM) is an open framework that pictures the current security situation in your project/organization and helps formulate and implement a software security strategy tailored to specific risks. Both BSIMM and SAMM are similar in their approaches to evaluation. They provide an understanding of what can be introduced and improved from a security standpoint. Depending on need, you may use SAMM to measure your organization’s past and present security practices to track improvements and determine a future course of action or use BSIMM to compare your organization’s security practices with those of other companies and industries.
SDL
Security Development Lifecycle (SDL) is the most common maturity model that introduces security and privacy considerations throughout all development phases. It helps developers build highly secure software, address security compliance requirements, and reduce development costs. SDL (or SSDLC) supports:
Inspection of the current maturity level (Level One, Level Two, or Level Three)
Project transformation (instructions on how to move to the next level)
Guidance on how to implement Secure SDLC practices
Last updated