Baking Security into DevOps: Tips for Enablement

When the pandemic hit, a lot of companies had to quickly change their business model. In fact, many started missing certain security aspects that were a tradeoff for having fast development cycles and delivering new features for customers. It’s time to go back and revisit the security policies and guidelines and how to best integrate them into the agile development process.

The biggest challenge for many organizations today is that the security team is almost always separated from the engineering and operations organizations. With emerging cloud and cloud-native technologies, it’s becoming overwhelming for the security team to centrally manage, monitor and work with the engineering team’s workflow.

To create a security mindset within the engineering organization, security teams must enable engineering teams with the tools that suit their workflow. If a security team’s solution is to just put wrapper code on top of the tool that security teams mandate, it’s going to become an added management technique which can slow progress.

SEE ALSO: Why Security Needs to Be Integral to DevOps

Baking security into the agile and DevOps way of working

A lot of people think speed will be reduced when security is baked into the process, but it’s a misconception. Time to market is often delayed if the security policies and gates aren’t integrated or automated into the software delivery systems. Even if there is a centralized security team, making them part of the agile development process and overall DevOps transformation journey will help all teams move faster and more efficiently address security issues as they arise.

DevOps is largely symbolized by the concept of an infinite continuous feedback loop. If we think of security practices sitting on top of this infinity symbol, security policies are integrated from beginning to end – plan, build, configure, test, analyze, and monitor. This depicts one set of common goals that can be distributed to different application teams, and enable them to take ownership for certain security tactics rather than one centralized team owning the responsibility and mandates of the security policies.

Here are some steps and practices to consider:

• For starters, engineering and operations teams need to anticipate the threats, not just at the application level but at the infrastructure level. Being reactive to the issues that arise is troublesome. Teams need to be proactive to the situation. That’s a mindset people are creating now that was not necessarily present when the pandemic first hit.
• A centralized or federated security model is practical but cannot be implemented on day one. Before this organization-wide model is established, it has to go through gradual transformation to understand the holistic view of software delivery management. Just like Agile, it’s a framework which needs to be scrutinized and improved over time.
• Build a common approach that consists of defining the key security policies needed in terms of static code analysis, dynamic code analysis, and the monitoring of code vulnerabilities. Those policies can be automated and orchestrated from a platform perspective for the application teams. This makes it easier for security leaders to gain visibility and insights from each of these different teams. It also creates that necessary feedback loop of what gaps are present and how to improve.
• Providing API integrations as part of a platform approach – pushing the code from the development to the production environment – will help ease the engineering team’s workflows by not having to worry about the added security techniques at each stage because it is already baked into the system. A no-code or low-code platform makes it easier to plug in the security tooling and run it.
• Whether or not you empower engineering and operations teams with their choice of tooling, an emerging practice is to take advantage of a scalable, no-code integration orchestration platform that compliments engineering and operational processes. This will enable security practices to be followed and can be managed and maintained at the speed of which they’re delivering software.
• Study the landscape of each application including the technology used, and how consumers are using the solution. This creates a baseline across all applications irrespective of technologies, cloud infrastructure, platform, etc. This will help root out false positives from a security threat perspective and give a clearer picture as to the next steps. If the false positive is always a mandatory security remediation (even when it may not be an actual threat), the velocity of software delivery is impacted.

For example, with Spring Boot Microservices and Node.js. In the Spring Boot Microservices, you may have a lot of false positives coming out as a high alert, critical vulnerability. In reality, these are not critical vulnerabilities to stop the code from being deployed to production. This consideration has to be looped into the security policies to understand the need of it, grant the exception, and manage the security exceptions going forward. This gives a baseline of managing exceptions to allowing the code to go to production in the first place. If security teams continue to stop the process because of these kinds of false positives, and not understanding the application landscape and business needs, security can become a nuisance for the executive team and business at-large.

SEE ALSO: 10 Benefits of CI/CD for your DevOps Journey

Expect the pitfall, and avoid it

The most common pitfall is the security team not having an adequate understanding of the application landscape, and how this has a downstream impact on the business, with respect to the company’s product portfolio and platform landscape. Security teams need to be trained across all four of these landscapes to understand what policies and guidelines need to be implemented.

From a software engineering perspective, there is always a push for greater velocity. But, thinking strategically about the security framework isn’t always part of that mindset.

Centralized security teams often push for having policies in place for every piece of code that gets pushed into production. But the security team may not offer the API integrations, for example, to make this process easier. Implementing the security policies alone is not going to do any good.

Ultimately, the goal is to create a partnership between the centralized security team and software engineering team to deliver on the promise of a DevOps transformation journey. To ensure the unique code that is developed and deployed is secure takes a gradual learning process and a greater understanding of the needs of the application teams and software delivery systems. Only then can a security framework be built on top of it. This evolution in approach and thinking will make it easier to adjust to emerging threats in the future and provide the visibility and control the business needs in these uncertain times.

The post Baking Security into DevOps: Tips for Enablement appeared first on JAXenter.