We’ve talked a lot about the benefits of DevSecOps, how DevSecOps can transform your organization, and how DevSecOps can significantly reduce risk. But how do you actually get started with DevSecOps? And how do you do it without burdening developers or slowing down production? Excellent questions. The good news is, getting started with DevSecOps is simpler than you might think. The key is to start small and take a phased approach.
In this blog, we’ll walk through a four-phase approach to standing up a DevSecOps program in just 90 days. This approach won’t fit every organization perfectly, so we encourage you to adapt it to your organization’s needs and objectives to create a truly sustainable DevSecOps program. Ready to get started?
As with any project, the foundation of your program is the most important part. It doesn’t matter how strong any other element is – if it’s not resting on a firm foundation, it will collapse. And with DevSecOps, the collapse will happen quickly. Here’s how to avoid disaster and set up for long-term success:
Security champions programs are an excellent way to build strong relationships between development and security teams. These programs designate developers on various teams as security liaisons to serve as a bridge between Security and Development. Their job is to communicate the goals, issues, and feedback between the two. These programs eliminate roadblocks, speed up timelines, and strengthen interdepartmental relationships.
To get started, security leaders should meet with development team leaders to discuss the goals of the program and identify team members who may be willing to act as security champions. It is important to make sure security champions are recognized for this contribution. Rewarding this extra effort in performance reviews can help motivate individuals to take on security champion responsibilities.
When creating a new program, feedback loops are the most important tool in your toolbox. Getting input from developers, stakeholders, users, and security team members about security processes, features, and controls is critical to building a sustainable DevSecOps program. We’re also using the word “loop” very intentionally here. Feedback should not be one way, but a reciprocal process, with information flowing back and forth between departments.
Surveys, check-in meetings, and user discussion boards are all good ways to collect feedback. Deploying different collection methods ensures you receive a variety of feedback and the context you need to adapt security practices appropriately.
The adage “walk before you run” rings very true here. Before you implement complex automations and orchestrations of DevSecOps, you must ensure you have the basic security testing tools in place (e.g., Static Application Security Testing (SAST), Software Composition Analysis (SCA)). These tools will provide you with the data and insights you need to eventually take those more advanced steps.
Spending time properly configuring these basic tools will also prevent a lot of headaches down the road. The temptation to move on to automation and more exciting technology will be strong, but spending time tuning these tools to your threat landscape, organizational objectives, and reporting obligations will make life a lot easier as you move forward. It is also important that you carefully scale up these tools, so you don’t overwhelm your developers with hundreds of vulnerabilities. Take a phased approach to configuration and work with your developers to ensure you aren’t burdening them.
After you’ve implemented the foundational elements of your DevSecOps program, you’re officially allowed to get started on more targeted projects. But don’t get carried away.
Using your security champions program, identify a development team that is willing to be a “guinea pig” and test out some of the security measures you want to implement. This approach will let you test out controls and identify issues before you roll out processes and solutions more broadly.
This is also where your feedback loops become critical. When working on this pilot program, ensure the development team you’re working with has direct access to your team and can submit feedback on what is and isn’t working. Encourage a constant dialogue to make sure the proper controls are being implemented without causing too much friction.
In DevSecOps, we often talk about the need to “shift left.” Shifting left is essentially integrating security processes and policies into DevOps at the start of a project, which eliminates roadblocks, helps with planning, and ensures a smooth deployment.
Threat modeling is an important step to incorporate at the start of a development project. Threat modeling identifies risks and potential compensating controls, which you can begin weaving in as the project ramps up. By performing threat modeling at project inception, you reduce the risk of surprises during security testing and build more secure products. Or if you’re working on securing an existing application, you can still perform retroactive threat modeling. Either way, threat modeling helps developers maintain timelines, avoid significant rework, and build higher quality products.
When you’re in the early stages of your DevSecOps program, known vulnerabilities are an excellent starting point. Some of the applications and tools in your environment likely have existing, identified issues that should be addressed. Many times, these can be quickly solved with configuration adjustments. SCA tools (open source or otherwise) can mitigate basic vulnerabilities in application dependencies, often just requiring simple fixes like updating software libraries.
These open-source vulnerabilities are low-hanging fruit. Solving them is a good first step for new teams to test out tools, policies, and controls before moving on to bigger projects.
Now that you have a strong foundation and have a few small projects under your belt, it’s time to implement some additional processes and tools to strengthen your program.
CI/CD pipelines are probably an integral part of your DevOps program already. Leveraging them for security can make for a more organic DevSecOps integration. CI/CD pipelines are an excellent opportunity to integrate security into automated workflows, and this approach reduces the amount of manual action required from either team to address security considerations.
However, it is important that you approach this integration slowly and carefully. Building security into CI/CD pipelines can easily overwhelm your development team if not planned thoughtfully. First, only integrate one security tool into a pipeline at a time, so you don’t overwhelm your development team. You can’t require developers to address every security vulnerability that pops up. Instead, consider your organization’s risk appetite and determine what is actually feasible and necessary for the development team to address. Perhaps it’s best to just focus on critical or high-risk vulnerabilities at this stage. This balanced approach makes DevSecOps more sustainable and manageable for developers as they quickly release new features and code.
Another way to integrate security in DevOps is to build it into infrastructure templates, which developers use to rapidly deploy new products and features. This will make security a routine part of provisioning new features and ensure it is considered during the development process.
Container registry deployment is a good use case for this. If your team is deploying from a container registry, make sure appropriate security controls are in place in this registry. Then when the time comes to deploy, Development doesn’t even have to think about security, because your team has already ensured security controls have been built into the container registry.
To be successful, you must work with developers in advance to implement security controls into infrastructure templates early on to ensure deployment timelines are not impacted.
We’ve talked a lot about the importance of feedback, so we’ll make this quick. Use the feedback mechanisms you previously put in place to understand the key pain points of the first 90 days across the organization. Identify root causes, brainstorm on solutions, and roll them out. Responding to feedback is a critical step in keeping the feedback loops active – take visible action based on the inputs you’ve received!
Now that you’ve set the stage, it’s time to build out your toolset and integrate processes across the business.
The integration of your development and security toolsets is important for expanding your program. Workflow management is a great place to start. For example, integrating security findings from your SaaS tool into Jira to create tickets for your development team can really streamline DevSecOps processes. Again, it is important to focus on key issues, so you don’t flood developers with tickets, but this is a great way to leverage your developers’ existing tools to meet your security objectives.
Vulnerability scanning, security monitoring, and source code management tools are also important tools to add to your DevSecOps toolbelt.
While your security team should always have a large role to play in DevSecOps, it’s also important to encourage developers to take ownership of security whenever possible. They should be equipped to own security issues and identify solutions to them. The key is making security a core product feature, something we’ve talked about in the past. By shifting Development’s perspective from security as a burdensome task to security as a key feature of a high-quality product, developers should feel more motivated to identify, address, and monitor security issues.
In addition, rewarding developers for an increased focus on security is important to balancing the responsibility for security. Tracking security metrics and rewarding successful teams can help motivate developers to own security.
Equipping your development team with scanning tools, access to vulnerability management platforms, and a clear channel for requesting security assistance will empower your developers to share the responsibility for security.
One of the best things you can do is ensure developers are trained in secure coding. This knowledge reduces the need for elaborate security controls and makes security testing run smoothly. But it’s important to not expect them to go from 0 to 60 overnight. Develop a learning plan that is relevant to your organization (e.g., if your team uses Java, make sure your training is for secure coding in Java) and allows them to build these skills over time.
After implementing these steps, there are a number of things you can do to continue to advance your DevSecOps program. Here are a few of them:
Whether you’re just getting started with your DevSecOps program or are looking to advance and expand you’re existing program, we hope you find the tips in this blog post helpful. Every step in this plan won’t work for every organization, but the principles of starting small, building a strong toolset, listening to feedback, and taking a phased approach are applicable to most. If you are looking for a partner in your DevSecOps journey, Focal Point’s experts offer a range of services – from program evaluations to CI/CD pipeline buildouts to AppSec tool suite selection.
Subscribe to Focal Point's Risk Rundown below - a once-a-month newsletter with templates, webinars, interesting white papers, and news you may have missed. Thousands of your colleagues and competitors have signed up! You can unsubscribe at any time.