There is an old saying that you can pick only two of the following traits: good, fast, and cheap. If you choose a good and fast path, it will be expensive. If you choose good and cheap, it will take time to get it delivered. Lastly, the fast and cheap selection will yield poor quality.
Over the past decade, companies have embraced DevOps methodologies, and understand the tough selection between the three traits. Tool selection is extremely important to implement a DevOps culture, although it will require more than just the perfect tool.
Successfully implementing DevOps, as a culture and practice, is predicated on automation. Efficient automation is how a company like Etsy does 50 deployments per day. This speed of development and deployment has some obvious advantages—bugs don’t live in production very long because rapid development and deployment replaces them very quickly with corrected code. You can also introduce new features quickly without having to wait for long development cycles to create a complete package. A new feature can be developed and deployed while other features are being developed alongside.
Like DevOps, DevSecOps is a culture. Security-minded companies are often the first to adopt DevSecOps methodologies, where developers work closely with security teams and bring security considerations earlier in the development life cycle — also known as “shifting left.”
In a typical (and simplified) software development process, you might have a requirements phase, followed by design/development, testing, and deployment. Shifting left means introducing security as far to the left in this software process as possible.
The security tools you use are essential to enabling and automating DevSecOps. You need to make sure you are selecting toolsets that will integrate with your existing environment, and support development from the source code repository, through the build process, testing, and deployment. These tools should also be API-enabled so that your developers can leverage them programmatically using automation.
Following are some ways that you could consider introducing security into the development process.
Adding DevSecOps in development processes
Requirements
The best place to introduce security is in the requirements phase. There are significant cost increases to fixing problems in later phases. There may be several ways of addressing
security in the requirements phase but a simple one is threat modeling and ensuring that the identified threats have mitigations in place.
Design/development
The same threats identified in the requirements should be kept in mind during the design and development phase. Designing how the product is going to operate should not introduce new threats while limiting the impact of existing threats that couldn’t be removed. Additionally, developers should always be following secure programming practices that are specific to the language they are using. Additionally, in cases where developers are expected to write test cases, they should be trained to write misuse cases and test against those so their software is more resistant to bad or malformed data being passed through functions they write.
Testing
All requirements should be addressed during testing, but specifically, any threat mitigation identified in the requirements phase should be tested to ensure the mitigation is in place and works. This is a case where misuse and boundaries should be tested. Data should be introduced that would violate the specifications to try to ensure any application failure is safe, meaning it doesn’t present an attacker with the opportunity to manipulate the program space or introduce and run code in a way that violates acceptable risk.
Deployment
The deployment phase may be one of the most critical, especially in the case of web applications or any application that is hosted in a network environment. All systems and containers that are deployed should be hardened, meaning unnecessary software or services should be removed and all access requirements reviewed and tightly controlled. The goal of deployment should always be to limit the attack surface, meaning the ability of an attacker to see any service from either the internet or within the network space controlled by the deployment team. This is also where you implement any changes based on observations from your production environment. Lastly, policy violations that exceed acceptable risk should be addressed before moving anything beyond this point.
Getting started
If you’re in an organization where security and development remain separate until applications are deployed and running in production, adopting a DevSecOps methodology can be challenging, especially when you have well-entrenched development processes. The cultural change alone could be met with resistance by your teams.
It may be easier to slowly push your way backward from the far right. While security testing is a minimum to push to production, you can steadily introduce secure programming practices and threat modeling into your workflows. It’s worth noting that security will typically require specialized staff, and you may not be able to find a single person who understands security from the perspective of all phases, so you’ll be adding additional bodies to your development team.
However, the increased investment in DevSecOps will pay off once you realize that security concerns, especially those that were not addressed earlier in the development process, are one of the driving forces behind deployment delays.
Sobre el autor
Ajmal Kohgadai is Principal Product Marketing Manager for Red Hat Advanced Cluster Security for Kubernetes. Prior to its acquisition by Red Hat, he was the Director of Product Marketing and Growth at StackRox, a leading Kubernetes security company.
Más similar
Navegar por canal
Automatización
Las últimas novedades en la automatización de la TI para los equipos, la tecnología y los entornos
Inteligencia artificial
Descubra las actualizaciones en las plataformas que permiten a los clientes ejecutar cargas de trabajo de inteligecia artificial en cualquier lugar
Nube híbrida abierta
Vea como construimos un futuro flexible con la nube híbrida
Seguridad
Vea las últimas novedades sobre cómo reducimos los riesgos en entornos y tecnologías
Edge computing
Conozca las actualizaciones en las plataformas que simplifican las operaciones en el edge
Infraestructura
Vea las últimas novedades sobre la plataforma Linux empresarial líder en el mundo
Aplicaciones
Conozca nuestras soluciones para abordar los desafíos más complejos de las aplicaciones
Programas originales
Vea historias divertidas de creadores y líderes en tecnología empresarial
Productos
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Servicios de nube
- Ver todos los productos
Herramientas
- Training y Certificación
- Mi cuenta
- Soporte al cliente
- Recursos para desarrolladores
- Busque un partner
- Red Hat Ecosystem Catalog
- Calculador de valor Red Hat
- Documentación
Realice pruebas, compras y ventas
Comunicarse
- Comuníquese con la oficina de ventas
- Comuníquese con el servicio al cliente
- Comuníquese con Red Hat Training
- Redes sociales
Acerca de Red Hat
Somos el proveedor líder a nivel mundial de soluciones empresariales de código abierto, incluyendo Linux, cloud, contenedores y Kubernetes. Ofrecemos soluciones reforzadas, las cuales permiten que las empresas trabajen en distintas plataformas y entornos con facilidad, desde el centro de datos principal hasta el extremo de la red.
Seleccionar idioma
Red Hat legal and privacy links
- Acerca de Red Hat
- Oportunidades de empleo
- Eventos
- Sedes
- Póngase en contacto con Red Hat
- Blog de Red Hat
- Diversidad, igualdad e inclusión
- Cool Stuff Store
- Red Hat Summit