Prácticas recomendadas

Al implementar un nuevo DevSecOps mecanismo, es fundamental tener en cuenta las distintas fuentes de autoría del código y cómo se potenciarán o se bloquearán potencialmente. A menudo, es posible que los ingenieros solo interactúen con una de estas fuentes. Sin embargo, la introducción de un nuevo mecanismo puede poner de relieve nuevas fuentes de autoría o poner de relieve los problemas planteados por fuentes que antes no se habían considerado. Exploremos cada uno de los siguientes aspectos con más detalle:

• Desarrolladores del equipo de aplicaciones: son los desarrolladores responsables del código principal de la aplicación. Deben estar facultados para realizar cambios y actualizaciones en el código de la aplicación según sea necesario, pero su trabajo también debe estar en consonancia con el nuevo DevSecOps mecanismo.

• Desarrolladores de infraestructura central: este equipo es responsable de la infraestructura principal de la organización, como los recursos de la nube, las redes y la seguridad. Deben participar en la definición de la infraestructura como código (IaC) y en los procesos de implementación para garantizar que el nuevo mecanismo se integre sin problemas.

• Bases de código abierto y de terceros: es habitual el uso de bibliotecas y componentes de código abierto de terceros. Sin embargo, estas fuentes deben gestionarse y protegerse cuidadosamente dentro del nuevo DevSecOps mecanismo.

• Código y artefactos reutilizables: promover la creación y el uso de códigos y artefactos reutilizables puede mejorar la eficiencia y la coherencia, pero la propiedad y la gobernanza de estos recursos compartidos deben estar claramente definidos.

• Repositorios y contribuciones compartidos: permitir la autoría colaborativa de código a través de repositorios compartidos puede ser beneficioso, pero requiere una gestión cuidadosa del acceso, las políticas de fusión y las revisiones del código para mantener la calidad y la seguridad.

• Estrategias de ramificación para IaC: la metodología Git no es directamente compatible con los patrones de diseño de infraestructura comunes. Es posible que sea necesario adaptar las estrategias tradicionales de ramificación para que la IaC se adapte a los desafíos únicos de la administración de la infraestructura. Esto podría implicar el desarrollo de flujos de trabajo especializados que tengan en cuenta la naturaleza funcional de la infraestructura, la posibilidad de que se produzcan desviaciones y una coordinación cuidadosa a la hora de realizar cambios en los entornos activos.

• Administración del estado: administrar el estado de la infraestructura es crucial en la IaC. Una gestión del estado adecuada garantiza que la infraestructura real se alinee con el código definido y evita conflictos o cambios no deseados. La implementación de prácticas sólidas de administración del estado, como el uso de mecanismos de almacenamiento estatal remoto y bloqueo estatal, es esencial para mantener la coherencia y prevenir conflictos en entornos multiusuario.

• Seguridad: en el contexto de la IaC DevSecOps, la seguridad debe integrarse en todas las etapas del ciclo de vida de la infraestructura. Esto incluye proteger la propia base de códigos de la IaC, implementar controles de acceso con privilegios mínimos, cifrar los datos confidenciales y analizar periódicamente para detectar vulnerabilidades tanto en el código de infraestructura como en los recursos desplegados resultantes. Los controles de seguridad automatizados y las validaciones de conformidad deben incorporarse al proceso de integración y entrega continuas (CI/CD) para garantizar que las mejores prácticas de seguridad se apliquen de forma coherente.

Diseñar un DevSecOps mecanismo que capacite y apoye eficazmente a equipos dispares requiere identificar todas las posibles fuentes de autoría de código y comprender sus necesidades y desafíos. Este enfoque ayuda a garantizar una implementación y adopción fluidas del nuevo mecanismo en toda la organización.

El diseño de DevSecOps los mecanismos va mucho más allá de los aspectos técnicos. El diseño y la implementación de DevSecOps los mecanismos tienen implicaciones de gran alcance. El equipo responsable debe considerar cuidadosamente los factores culturales, organizativos y humanos. Esta consideración ayuda a garantizar que la solución no solo cumpla con los requisitos técnicos, sino que también fomente un entorno de trabajo positivo, productivo y atractivo para todas las partes interesadas. Lograr el equilibrio adecuado es crucial para el éxito a largo plazo y la satisfacción de los empleados.

Considere los siguientes escenarios relacionados con el diseño y el despliegue de DevSecOps los mecanismos:

• Amplificar la disparidad entre desarrolladores y responsables del mantenimiento: la implementación de un sistema que facilite a los desarrolladores ansiosos la entrega rápida de soluciones puede poner de relieve inadvertidamente la aparente falta de trabajo de los mantenedores. Los encargados del mantenimiento son personas con títulos de desarrolladores, pero sus day-to-day responsabilidades han pasado a centrarse en el soporte y la estabilidad de las aplicaciones existentes. La falta de nuevas contribuciones por parte de los mantenedores podría haber sido menos visible en el pasado. Esta situación podría llevar a la organización a infravalorar los conocimientos y la experiencia fundamentales de estos mantenedores, lo que podría provocar resentimiento y una disminución de la moral.

• Repeler a los desarrolladores con una solución demasiado controlada: crear una solución altamente controlada DevSecOps que resulte engorrosa de utilizar para los desarrolladores deseosos de utilizarla puede atraer a los mantenedores. Sin embargo, la solución podría alejar a las personas que la organización necesita para impulsar la innovación. Obligar a los desarrolladores a aprender un mecanismo de CI/CD patentado además de sus lenguajes de aplicación y programación puede suponer un obstáculo importante para su adopción. Una DevSecOps solución altamente gestionada podría convertirse en un desincentivo para los desarrolladores con talento.

• Arriesgarse a la incompatibilidad y la disrupción culturales: la implementación de un DevSecOps mecanismo que es culturalmente incompatible con las formas de trabajo actuales de la organización puede generar fricciones y resistencias significativas. Si el enfoque del mecanismo (por ejemplo, prescriptivo en lugar de consultivo) no se ajusta a la cultura de la organización, es probable que no se adopte. Como resultado, algunas partes interesadas podrían sentirse frustradas y creer que la organización está avanzando hacia una burocracia innecesaria.