Secure Development for Agile Workflow

Secure Development Lifecycle

How to Incorporate Secure Practices Without Choking Development

The Secure Development Lifecycle is a process that can reduce the occurrence of security-related bugs and increase reliability and privacy. SDL integrates security and privacy considerations into every phase of development, resulting in highly secure software that meets compliance requirements.

It starts with security requirements as part of the outline of the client’s needs. A risk assessment and threat model are then completed, followed by secure coding, automated testing, and manual code review. Penetration testing is performed before the thread model is repeated. When all vulnerabilities are addressed, the application can be uploaded to production by a separate team, and ongoing monitoring can begin.

Benefits and ROI: Is SDL worth it?

Yes, SDL increases overall ROI. Initially, incorporating SDL seems disruptive and more costly than your existing development process on the surface, but it prevents the occurrence of security-related bugs and change requests in the later stages, which is far more complicated and expensive. Implementing security in the requirements and design stages identifies security issues and bugs and allows the team to address them while progressing in the development process. It’s a far more efficient process and saves money overall.

All Security Controls in SDL

These are the security controls that are possible to incorporate as part of the secure development lifecycle, but they are not all necessarily recommended as the most efficient means of optimizing security, hitting release deadlines, and maximizing ROI. Following this list are our recommendations for integrating SDL as part of an Agile environment without choking the development process.

Security Requirements and Design

A list of requirements should be assembled before the creation of a high-level design (HLD). These requirements will reflect the needs of the business. All security needs should be added to this list by the CISO as well. Include legal obligations for privacy and security. This ensures that the security needs are understood and considered from the very beginning. Ongoing requirements like secure coding practices and input validation do not need to be added to the list. A solution with embedded authentication should have requirements such as:

• Credentials should be sent encrypted
• Two-factor authentication (2FA) should be embedded
• Password reset should not use the same channel as the 2FA
• User account should be temporarily locked after ten consecutive failed attempts
• Authentication should not be federated with any service unless approved by the CISO

Risk Assessment & Threat Modeling

Once the HLD is complete, conduct risk assessment and threat modeling to map weaknesses and security gaps. This will identify and mitigate risks before they breach your acceptance level. All risks that are mapped in this phase and their countermeasure controls should be documented for verification in later development.

Secure Coding

Secure coding practices are relevant to anything that the development team produces. It’s an ongoing effort to verify that the development code practices and developer knowledge are appropriately aligned with the company’s security goals and targets. Secure coding can be taught or reestablished in training, workshops, or online solutions.

QA & Security Tests

Security testing begins when coding is almost finished, during the QA/testing phase. Running automated testing tools before manual code review speeds up the process by getting most issues and errors out of the way. Then manual review can be conducted to ensure the strength and integrity of the code.

Static Application Security Testing (SAST)

Automation in code review not only accelerates the process but can also detect gaps that would otherwise be overlooked. An automated SAST tool can quickly reveal common and in-depth security holes for fast remediation by developers. The best SAST supports most of the languages used in the code that’s being tested.

Dependencies Weak Version Detection

Another aspect of code review that can be automated is the detection of weak versions within the code. As with SAST, these tools are often categorized by the coding language and the repository. The tool used should be compatible with the applications being diagnosed.

Dynamic Application Security Testing (DAST)

DAST tests the application after uploading it to a staging server. It’s the closest value you’ll get to an automated penetration test, apart from conducting actual penetration testing.

Code Approvals

Once all issues raised during automated testing are resolved, the code should be reviewed by a developer who was not involved in writing the code. This review is meant to identify any weak coding, back doors, and insecure configurations and verify that the code’s logic is solid. There are many online security training options for secure code review.

Penetration Test (PT)

Penetration testing tells you how resilient your application will be against a malicious attacker so you can minimize the risk of actual damage. This phase tests the final product for vulnerabilities that could be exploited by simulating various cyberattacks and is often considered the final security maturity test before releasing to production.

Risk Assessment & Threat Modeling

When all other testing and review stages are complete, the risk assessment and threat modeling should be repeated.  This helps devs verify that all findings from the initial assessment have been remediated and that no other threats have been created during the different stages of development.

Uploading to Production

Dev-ops or IT should be responsible for the upload to production. This prevents the creation of new security concerns with the development team having access to too many assets. A developer with admin access to a production server could bypass the security controls and upload their own code.

Monitoring

Once a service is uploaded and online, ongoing monitoring will help minimize and prevent attacks. Your team can identify attacks in real-time and avoid damage by maintaining log collection, monitoring illicit behavior, and sending alerts based on anomaly detection.

SDL for Agile Workflow

Implementing that entire process in an Agile workflow is likely to choke the process, slowing development and preventing timely delivery. This adjusted version of the SDL list provides the best ROI and security value with minimum weight and overhead on the development process.

Security Requirements

Making security requirements part of your pre-HLD requirements list doesn’t add much cost or time and is crucial to the success of the process. Without this step, the dev team is much more likely to miss legal security obligations and stakeholder requirements. We recommend keeping this step as part of your Agile SDL.

It is also worth considering running threat modeling on core-design\impactful changes, since this is not a standard operation in agile workflow, it often doesn’t get its own stage.

Secure Coding

Secure coding should be part of your developers’ training and should not change the development process from its existing format. This step is considered a benefit to the developers and should not be left out of your SDL process.

Q&A and Security Tests

Automated Testing

The automated testing processes SAST, dependencies weak version detection, and DAST have very little manual activity required and are light on overhead to the development process when appropriately implemented. Keeping these processes as part of your Agile SDL offers significant benefits over cost.

Code Approval

Manual code review and approval are critical and essential because all security tests were automated up to this point. While automated processes are efficient at identifying some mistakes, some logical mistakes in the code are not likely to be found until the manual review.

Periodic Penetration Testing

Penetration testing should be conducted annually and after any significant changes instead of running it for every version. If your risk appetite is low, you can run small penetration tests on specific scopes throughout the year. These tests will focus on changes to the application since the last test. Time should be reserved for developers to address vulnerabilities as soon as possible after each penetration test.

Upload to Production

Uploading to production has to be done anyway, so it should be done securely. The development team that wrote the code should not be involved in the upload to production because this grants too much access to a single team.

Monitoring

Attacks will happen regardless of the security measures you implement during development. Ongoing monitoring identifies attacks and enables you to respond at an early stage. Without monitoring, you may learn about attacks only after critical damage is done