Developing and deploying AI-powered systems and applications is a complex business, especially in our extended remote reality. You’re likely facing an uphill climb and let’s face it, huge risks. The way to clear the obstacles, lower the risks, and raise the value you deliver hinges on one essential element: implementing DevSecOps to protect your process and your assets.
We’re operating in a different world now where unity among development (Dev), security (Sec), and operations (Ops) has never been more essential. Compounded by pressure related to the fast need to convert many of our office infrastructure to meet the needs of our remote reality during the COVID-19 pandemic, the market for DevSecOps is projected to grow from 32% to 34% mid-decade.
Long before the pandemic, we decided early on at Modzy® to establish a DevSecOps practice for ourselves. As a remote-native company, Modzy needed the guardrails that robust, resilient DevSecOps can deliver. It’s been a journey well worth taking, especially during the disruption of last year, leading us to share some insights as you consider your own DevSecOps. (If you’re not thinking about this, move it to the top of the list. That’s how critical it is.)
To bring value to your engineering organization, applying fundamental security principles to the security portion of DevOps is a solid foundation for making trusted AI work.
What is DevSecOps and why do you need it?
DevOps, simply put, is the discipline of creating a process by which code moves quickly from a developer’s environment to a production environment while ensuring the requisite quality. Humans, as it turns out, are really bad at doing the same thing exactly the same way over and over again. Computers, on the other hand, are really good at it so it’s common that DevOps processes are heavily automated.
DevSecOps is the discipline of weaving security best practices into the DevOps process so that security is applied at each step along that process. By making security an integral part of software development rather than something bolted on at the end, you increase value and decrease risk. It’s a simple as that.
What isn’t simple is the complicated reality of developing software today. Over time, we’ve gone from Bash scripts to Perl scripts to infrastructure automation like Puppet and Chef, to virtual machines, containers, container orchestrators, infrastructure-as-code, and it keeps going.
A look at JavaScript reinforces this point. Chances are, your Web application is written in something like JavaScript (for example, TypeScript) but is not actually JavaScript and requires not one, but at least two different transpile steps before it can be delivered in a form that can be consumed by a browser.
The point is that modern applications have many more layers than before. They all need to be coordinated before the application can be shipped.
Similarly, the adoption of microservices has given rise to a whole new suite of coordination tools like Eureka, Zookeeper, Consul, and Kubernetes. Some microservice-based applications even go so far as to require sidecar proxies such as Envoy so microservices can communicate with each other.
To achieve a rapid, quality delivery with all these extra layers and coordination, a mechanism is needed to ensure the correct process is always followed in a consistent and deterministic manner. That’s why we need DevOps.
If you’re in the cloud and have your infrastructure as code, then it’s probably occurred to you to evaluate what IAM users, roles, and policies are created and what security groups and network policies are defined in your infrastructure code. However if you’re running something like Kubernetes on one of the major cloud providers, then any developer who can create a LoadBalancer service can cause not only new infrastructure to be automatically provisioned, but new security groups to be created that may or may not conform to your organization’s policies.
That’s why we need DevSecOps. It’s so important to consider security in your delivery process. As more and more of your application stack moves to the left and becomes code, you need to move your security practices to the left as well.
Security fundamentals are the key to safeguard assets and value
As we built Modzy, we made the guiding tenets of information security—confidentiality, integrity, and availability—central to our DevSecOps discipline. Consider their application for your organization.
Confidentiality is the principle that governs who has access to what information or systems. Think about all you need to protect—intellectual property, patented or proprietary information, internal security code, export-controlled data, environment configuration. You have to protect the secrets, and the things that have access to the secrets.
Integrity is the principle that requires that the data about your information and systems is accurate and reliable. The decisions you make here will drive the auditing and security alerting you set up as a part of your DevSecOps processes.
Availability is the principle that ensures the right people have timely access to your information and systems. The decisions you make here will determine what policies and monitoring you put in place.
At Modzy, these three principles guide how we practice and evolve DevSecOps. It’s been a game-saver for us, and we see real opportunity ahead for any organization to establish a consistent, repeatable path forward. When you develop software without DevSecOps, security problems can derail your efforts with expensive, time-consuming fixes. It’s better to integrate security at the front end to speed safe results and drive intelligence everywhere.
Watch for the next blog on how these security tenets fuel a successful DevSecOps practice.
https://searchitoperations.techtarget.com/tip/3-DevSecOps-trends-to-keep-an-eye-on
This blog has been republished by AIIA. To view the original article, please click HERE.
Recent Comments