Micro Focus is now part of OpenText. Learn more >

You are here

You are here

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

public://pictures/johanna.jpeg
Johanna Curiel Co-founder, Ossecsoft
 

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

As Daniel Cuthbert, head of security research at Grupo Banco Santander, wrote in "A call to arms for devs: Get revolutionary about security as code":

It is time to focus our efforts on defense—not the attacks—and make heroes of the people who can make a difference: Developers.

Jim Bird, CTO at BIDS Trading Technologies and a software and project manager with more than 20 years of experience in financial services technology, writes in an O'Reilly report:

Security as Code is about building security into DevOps tools and practices, making it an essential part of the tool chains and workflows. You do this by mapping out how changes to code and infrastructure are made and finding places to add security checks and tests and gates without introducing unnecessary costs or delays.
Jim Bird

So how does your team move beyond the concepts into 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. The worst mistake you can make is to try to execute security without understanding what it is.

An authoritative source on this subject is the OWASP Secure SDLC Cheat Sheet; though it's still in draft mode, it provides a nice overview. The following graphic shows activities that take place during each step of the development cycle. 

The arrow showing "shift left" illustrates the concept of embedding security early on by executing security practices, defined further below. Image courtesy: OWASP.

2. Assess your situation with SAMM

The Software Assurance Maturity Model (SAMM) is an open framework that helps organizations formulate and implement a strategy for software security that's tailored to the specific risks the organization faces. However, some people feel that this framework is complex to execute.

Until your organization can get a firm grip on SAMM, these questions will help you quickly evaluate the security component of your DevOps process:

  • Requirements: Are you gathering security and privacy requirements specifically for the software to be built? 
  • Design: Are you doing threat modeling on every sprint?
  • Development: Are you using static analysis and code review?
  • Test: Are you using dynamic analysis and security testing to verifying the security requirements?
  • Deployment: Are you planning to evaluate the final version using a pen test or do a risk assessment that includes a bug bounty program?

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

Many organizations focus their security efforts on the last stage of the cycle, deployment after pen testing. Unfortunately, this approach is the most costly if you then discover major vulnerabilities. And a big risk is that a pen test might not uncover any major problem that really does exist.

On the contrary, the "shift-left" movement is focusing more and more on embedding security from the beginning, which in the end is less costly and less risky.

3. Be mindful of the security challenges inherent in DevOps 

DevOps is a challenging process into which to embed security.  For example, think of security principles such as "least privileged," where the developer has access to production environments and can make any change. This contradicts most best-practice security concepts, but there is still hope to embed security when security as code comes into place.

Security can't be an impediment to the business, but it is necessary to find a balance between secure development and agile that has no form of security.

4. Implement security as code as quickly as possible

Embedding security during an agile sprint should be flawless, and almost automatic. This is the ideal situation, but it's quite hard to get right.

An alternative is to automate as much as possible in this process, including specific secure DevOps pipelines that should be must-haves. Everyone on the team should be aligned and stick to these ideas. 

5. Threat-model early on

Plan threat-modeling sessions at least one day before the sprint begins. All the potential issues and risks should become part of security stories.

6. Define security requirements early

  • Make sure to define your security requirements at the beginning of the sprint, including the threat-modeling issues. (Tip: Use the OWASP ASVS 2.0 to support this process.)
  • Make security requirements security stories and add them to the sprint backlog.
  • During the sprint definition, calculate how much work it will take to implement and create test cases to address these security stories/tasks. (Tip: Use the OWASP Testing Guidelines.)
  • Use the OWASP Proactive Controls during the development phase and make sure these controls become regular tasks during every sprint.

7. Use SAST/DAST tools 

  • Plug in static and dynamic analysis tools (SAST/DAST) during the build process. 
  • Make the results from the these scans regular sprint bugs. This should be done after a cleanup task, such as making sure you have eliminated as many false positives as possible.
  • If the code is changing too much, you might reconsider how you apply SAST, since many false positives arise when the code has changed considerably.
  • If your organization cannot afford for-pay tools, check out open-source alternatives such as the OWASP Dependency Check to at least find vulnerable components. 

8. Perform code review whenever possible

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

9. Measure risks and prioritize

The product owner—or whoever is performing this designated role in decision making—should have the proper security background to understand the issues and to be able to prioritize those that require the highest attention.

10. Prepare the security-as-code backbone

Any changes to environments (QA/UAT/PROD) should be done using code, manually. All the changes to configurations should be through code, using source repositories and tracking all changes. This can be achieved with any of the popular build, source code, and deployment tools. This is the backbone of the security-as-code concept.

Looking at the entire process, DevOps pipelines should focus on embedding activities that automate the process of continuous delivery. Here's what to focus on:

  • Changes to configuration in all environments should be source-controlled and peer-reviewed.
  • The build process should automate integration and deployment.
  • Carefully review configurations to containers with security in mind.
  • SAST tools should be integrated into the build process, and issues found should be fed back into the sprint.

11. Evaluate regularly, rinse and repeat 

Have SAMM evaluation sessions to check how completely you are implementing security, and create specific short-term tasks to achieve this. Step-by-step is the key.

Shifting left helps you stay ahead

Organizations that shift left are more effective at finding defects, and the damage and cost of fixing them is less than when developers deploy an application, or after it's released to production.

But the pressure for rapid delivery makes security by design more difficult. DevOps teams have a responsibility to validate security requirements in a short time. "Security as code" can play a big role in this, since it helps to automate the process of secure deployment, making the process easier and faster. 

How has your team embraced security as code? Share your best practices in the comments below.

Keep learning

Read more articles about: SecurityApplication Security