Con su cuenta de Red Hat puede acceder a su perfil de miembro y sus preferencias, además de a los siguientes servicios teniendo en cuenta su estado de cliente:
¿Aún no se ha registrado? Le ofrecemos varios motivos por los que debería hacerlo:
- Consulte artículos de la base de conocimiento, gestione casos de soporte y suscripciones, descargue actualizaciones y mucho más desde una misma ubicación.
- Consulte los usuarios de la organización, y edite la información, preferencias y permisos de sus cuentas.
- Gestione sus certificaciones de Red Hat, consulte el historial de exámenes y descargue logotipos y documentos relacionados con las certificaciones.
Con su cuenta de Red Hat puede acceder a su perfil de miembro, sus preferencias y otros servicios dependiendo de su estado de cliente.
Por seguridad, si está en un equipo de acceso público y ya ha terminado de utilizar los servicios de Red Hat, cierre sesión.Cerrar sesión
In this post:
Why DevSecOps is important
Some common challenges in implementing DevSecOps
How to start your DevSecOps journey
We recently published the results of our survey from earlier this year where we asked more than 500 IT and Security practitioners about their container and Kubernetes adoption and security strategies. One of the key takeaways was that organizations need to build a bridge between DevOps and security to realize the benefits of tools like containers and Kubernetes. This is because responsibility for securing cloud-native development tools like these is highly decentralized.
Our survey revealed that across various roles, DevOps is the single role most cited as responsible for securing containers and Kubernetes, but only according to 27% of respondents – hardly a majority.
Taken together, the myriad operational roles of DevOps, Ops, and DevSecOps are considered the primary owners of Kubernetes security by a whopping 66% of respondents. Echoing the need for security to shift left, 15% of respondents consider developers as the primary owners of Kubernetes security, with only 18% identifying security teams as being most responsible.This distribution shows that when it comes to container and Kubernetes security, multiple teams are involved. Traditionally, a Security team has been the central control point for enforcing security and compliance policies. Containers and Kubernetes adoption are often primarily driven by DevOps, so it’s not surprising to see respondents naming them responsible for securing these technologies.
To bridge these gaps, container and Kubernetes security tooling must facilitate close collaboration among different teams—from Developers to DevOps to Ops to Security—instead of perpetuating the silos that may plague organizations.
Most of your peers have started their DevSecOps journey
DevSecOps is no longer just a buzzword—the term encompasses the processes and tooling that allows security to be integrated into the application development life cycle rather than an afterthought. Our survey found good news on this front—the vast majority of respondents say
they have some form of DevSecOps initiative underway and 25% of respondents have an advanced DevSecOps initiative, where they’re integrating and automating security throughout the life cycle.
Navigating your DevSecOps journey
A good place to start on your DevSecOps journey is by learning from your DevOps journey. DevOps has come to reflect a culture that champions principles such as increased collaboration, shared responsibility between engineering teams that spans development and operations, removal of operational silos, and autonomous decision-making, all in the spirit of achieving greater speed and consistency.
DevOps relies on methodologies that leverage automation, continuous integration and delivery, and treating infrastructure and application components as immutable.
Challenges for implementing DevSecOps
These changes can place strains on existing security programs. DevOps-driven adoption of new technologies and processes may leave security as an afterthought or, in some instances, expose new gaps in security coverage and risk management. Security teams must therefore work toward a familiar set of goals for modern computing environments – avoiding security incidents, breaches, and exposures; establishing security best practices and policies to be implemented on an organization-wide basis; managing resources to minimize operational overhead, alert fatigue, tool sprawl, and manual investigative workflows – in ways that align with the approaches that engineering teams favor.
The introduction of new technical architectures and operational patterns associated with DevOps methodologies also results in security challenges that stem from greater complexity – for example, the number of cloud-native technologies that a single organization utilizes can easily climb into the dozens. The sprawl of smaller-sized application components running in containers, microservices, and serverless functions additionally makes it harder to ensure that scalable, strong security controls are applied uniformly across infrastructure and applications.
These challenges are often amplified by existing issues such as misalignment of priorities between engineering and security teams. Security teams are mandated to minimize risk and will disallow tools for which they lack adequate visibility, risk assessment, and control.
The practices that DevOps teams use to achieve scale and speed might make it harder to coordinate the implementation of security controls. However, DevSecOps holds the promise of leveraging these same DevOps principles to better align engineering and security teams on a common goal.
Three steps for beginning your DevSecOps journey
Because DevSecOps is based on the idea that security is everyone’s responsibility, the collective attention on security across engineering and security teams can lower risk for their entire organization. To successfully achieve DevSecOps as a goal requires an organization to understand and implement the following.
Security controls must be integrated continuously across the entire software lifecycle from the time that application components are built to when they are running.
Security should be implemented earlier in the lifecycle following a "shift left" approach so it can have an outsized impact on improving security and minimizing the overall operational overhead required.
It must be recognized that development engineers and DevOps end users are security users: they must be expected and empowered to implement and make independent decisions regarding security controls.
When adopted effectively, DevSecOps can enable an organization to secure their software environments with greater speed, at a larger scale, and more comprehensively when compared to using traditional security strategies that were not designed to safeguard modern infrastructure and applications.
About the author
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.