Security and AI: How to Make Sure DevSecOps Delivers Results

Software and systems are the backbone of most organizations. When an application fails or a system is breached, it can lead to dire loss and harm. While that may be stating the obvious, what isn’t always clear is how to protect assets as you develop and field new solutions. In our remote reality, the stakes have never been higher.

As more organizations adapt and adopt AI and machine learning to compete and prosper, there’s an even greater need to adopt a ‘security as code’ philosophy to ensure security issues don’t derail your plans to scale new solutions.

That’s what DevSecOps is all about: discovering and dealing with security concerns early in the software development process to avoid expensive fixes and risky outcomes. At Modzy, we want our software engineers (Dev), security experts (Sec), and operations team (Ops) in sync across the development lifecycle.

So we embraced DevSecOps early and built our practice around the three tenets of information security:
Confidentiality. Integrity. Availability. By embracing the discipline and practice of DevSecOps, we’re not only protecting ourselves, we’re helping our clients and users to realize the benefits:

• Faster software delivery
• Time and cost savings
• Automated security checks and testing
• Adaptive, repeatable process
• Less vulnerability/grater security

Infuse opportunities ahead, and defuse the risks, with DevSecOps. Here are five best practices that can make all the difference in your success.

1. Non-production environments should be considered ephemeral

Practice makes perfect. Or more accurately, perfect practice makes perfect. By regularly re-paving our non-production environments, we gain a couple things. First, we practice deploying and configuring our entire stack from scratch on a regular basis, quickly identifying areas that we have yet to incorporate sufficient automation.

Second, we clear out any cruft that is no longer relevant to ensure that we aren’t ignorantly reliant on something from past without any documentation. There is nothing more frustrating that promoting code to a new environment, only to find out it doesn’t work because something about that environment was slightly different than the environment it came from, and there’s no discernable reason why.

Ultimately the goal is to ensure the Integrity of our applications. So we prove to ourselves on a regular basis that we know exactly what we are deploying by wiping everything out and re-deploying from scratch with what we believe is necessary to run our product.

2. Nothing should be promoted or deployed except by automation

Similar to the previous best practice, this helps us ensure the Integrity of our product. Each promotion or deployment is done in a way that can be audited and does not rely on a human following a checklist perfectly every time. It also helps us preserve Confidentiality of our environments because humans no longer need privileged access to environments to do the deployments.

If you’re doing your development in the Cloud, Confidentiality can be further preserved by using completely separate accounts for dev, test, and prod, further limiting the access that humans have to those environments. For us, this gave us the freedom to grant more access to people in our dev environment (because we can re-pave it regularly) and no access at all to our test and prod environments outside our DevOps staff and automation tools.

3. Practice defense in-depth

You must take offensive and defensive action to truly protect your systems and secrets. Waiting until the tail end of development is risky business. It’s often costly and insufficient. Instead, increase your advantage by shifting your approach. Consider the implications along each step of the process and how adverse events during that step could compromise security later on.

4. Empower developers to be as self-sufficient as possible

We love our developers. All the process and security constraints that we are talking about must be done in a way that does not adversely affect our development team’s ability to move fast, experiment and test new ideas, and ultimately develop features quickly.

5. Educate yourself and find inspiration

When we were considering our own process, we were influenced by a number of sources. First, we drew from our own experiences, of things that went well or went poorly in the past. Next we asked present and former colleagues about their experiences. We also surveyed blog articles, conference talks, and other writings or presentations on the topic to try and benefit from others’ experiences. Personally, I always enjoy listening to talks from engineers at Netflix or Google or Amazon or others that have had to solve problems at a complexity and scale that I have not yet had the pleasure of experiencing myself. The hard-earned wisdom that is shared by those engineers can be invaluable, letting you learn from difficult challenges without having to experience the challenge yourself.

We also drew inspiration from what some might consider to be an unlikely source. For the past few years, the US Air Force has been compiling a list of best practices and recommendations for implementing a robust DevSecOps practice and has published a reference design.

While some aspects of the design are specific to the Defense Department, the recommendations to achieve a secure delivery process are widely applicable. They served as a great starting point for us as we considered our own process. Ultimately, the combination of bringing together your development, security, and operations teams and keeping discrete parts of your infrastructure separate and siloed are keys to establishing a strong DevSecOps practice for your organization.