How to deliver security as code: 11 tips to get started

Security as code and security by design are hot buzzwords at conferences these days. But what exactly do these phrases mean, and how can you start adopting them in your organization?

[[270725]]

As Daniel Cuthbert, head of security research at Grupo Banco Santander, writes in “A Call to Arms for Developers: Revolutionizing Security as Code”:

Now is the time to focus our efforts on defense — not offense — and make heroes of those who can make a difference: developers.

Jim Bird, CTO of BIDS Trading Technologies and a software and project manager with more than 20 years of experience in financial services technology, wrote in the O’Reilly report:

Security as code is about building security into DevOps tools and practices, making it an essential part of the toolchain and workflow. You do this by mapping how code and infrastructure are changed and finding where to add security checks and tests and gates without introducing unnecessary costs or delays.

- Jim Bird

So how does your team move beyond concept to action? Here are 11 tips to get you started.

1. Understand the meaning of 'Secure SDLC'

Understanding the secure software development lifecycle (SDLC) will help you evaluate how to build security into your specific DevOps situation. A big mistake you can make is trying to perform security without understanding what it is.

The authoritative source on this topic is the OWASP Secure SDLC Cheat Sheet; although it is still in draft mode, it provides a good overview. The following diagram shows the activities that occur at each step of the development cycle.

The arrow showing "moving left" illustrates the concept of embedding security early by executing secure practices, further defined below. Image credit: OWASP.

2. Assess your situation using SAMM

The Software Assurance Maturity Model (SAMM) is an open framework that helps organizations develop and implement a software security strategy tailored to the specific risks facing the organization. However, some people consider this framework to be complex to implement.

Until your organization has a firm grasp on SAMM, these questions will help you quickly assess the security components of your DevOps processes:

1. Requirements: Are you gathering security and privacy requirements specific to the software you are building?
2. Design: Do you do threat modeling every sprint?
3. Development: Do you use static analysis and code reviews?
4. Testing: Do you use dynamic analysis and security testing to validate security requirements?
5. Deployment: Do you plan to evaluate the final release using pen testing or conduct a risk assessment that includes a bug bounty program?

If your answers are mostly no, then you are in the early stages of implementing security — in other words, your DevSecOps efforts are at a very low maturity level.

Many organizations focus their security efforts at the very end of the cycle, deploying after pen testing. Unfortunately, this approach is costly if you discover major vulnerabilities. And a big risk is that pen testing may not uncover any major issues that do exist.

In contrast, the “shift left” movement is increasingly focused on embedding security from the outset, which ultimately costs less and carries less risk.

3. Be aware of the security challenges inherent in DevOps

DevOps is a challenging process to embed security. For example, consider security principles such as “least privilege” where developers can access the production environment and make any changes. This contradicts most best practice security concepts, but when security is in place as code, it is still desirable to embed security.

Security cannot become a hindrance to business, but it is necessary to find a balance between secure development and agility without security.

4. Implement security as code as soon as possible

Embedding security during an Agile sprint should be seamless and almost automatic. This is the ideal situation, but it is difficult to get right.

Another approach is to automate as much as possible in the process, including the specific security DevOps pipeline that should be in place. Everyone on the team should be aligned and stick to these ideas.

5. Early Threat Modeling

Plan a threat modeling session at least one day before the start of the sprint. All potential issues and risks should be part of the security story.

6. Define security requirements early

1. Make sure to define security requirements at the start of the sprint, including threat modeling questions. (Hint: use OWASP ASVS 2.0 to support this process.)
2. Make security requirement security stories and add them to the sprint backlog.
3. During sprint definition, calculate the effort required to implement and create test cases to address these security stories/tasks. (Hint: Use the OWASP Testing Guide.)
4. Use OWASP proactive controls during the development phase and ensure these controls become regular tasks during each sprint.

7. Use SAST/DAST tools

1. Insert static and dynamic analysis tools (SAST/DAST) into the build process.
2. Get regular sprints of error results from these scans. This should be done after cleanup tasks such as ensuring as many false positives as possible are eliminated.
3. If the code changes too much, you might rethink how you apply SAST, because many false positives appear when code changes a lot.
4. If your organization can't afford paid tools, look into open source alternatives such as OWASP Dependency Check to at least find vulnerable components.

8. Perform code reviews whenever possible

One task is to perform code review as part of the sprint. Any issues found here will become bugs at the end of the sprint.

9. Measure and prioritize risks

The product owner - or someone who performs this designated role in decision making - should have the appropriate security background to understand the issues and be able to prioritize those that require high attention.

10. Prepare a security code backbone

Any changes to the environment (QA/UAT/PROD) should be done manually using code. All changes to configuration should be done via code, using a source repository and tracking all changes. This can be achieved with any popular build, source code, and deployment tool. This is the backbone of the code safety concept.

Throughout the process, the DevOps pipeline should focus on activities that embed automated continuous delivery processes. Here are the things to focus on:

1. Configuration changes in all environments should be source controlled and peer reviewed.
2. The build process should automate integration and deployment.
3. Carefully review the configuration of your containers with security in mind.
4. SAST tools should be integrated into the build process and the issues found should be fed back into the sprint.

11. Evaluate regularly, rinse and repeat

Conduct a SAMM assessment meeting to check how completely you have implemented security, and create specific short-term tasks to achieve this goal. Taking it one step at a time is key.

Shifting left can help you stay ahead

Organizations that shift left are more effective at finding defects, and the loss and cost of fixing them is lower when developers deploy applications, or after an application is released.

But the pressure to deliver quickly makes it harder to design for security. It is the responsibility of the DevOps team to validate security requirements in a short time. “Security as code” can play an important role in this regard as it helps automate the security deployment process, making the process easier and faster.