Práticas recomendadas

Ao implementar um novo DevSecOps mecanismo, é crucial considerar as várias fontes de autoria de código e como elas serão capacitadas ou potencialmente bloqueadas. Muitas vezes, os engenheiros só podem interagir com uma dessas fontes. No entanto, a introdução de um novo mecanismo pode trazer novas fontes de autoria para o primeiro plano ou destacar desafios de fontes não consideradas anteriormente. Vamos explorar cada um dos aspectos a seguir com mais detalhes:

• Desenvolvedores da equipe de aplicativos — Esses são os desenvolvedores responsáveis pelo código principal do aplicativo. Eles devem ter o poder de fazer alterações e atualizações no código do aplicativo conforme necessário, mas seu trabalho também deve estar alinhado ao novo DevSecOps mecanismo.

• Desenvolvedores de infraestrutura central — Essa equipe é responsável pela infraestrutura principal da organização, como recursos de nuvem, redes e segurança. Eles devem estar envolvidos na definição da infraestrutura como código (IaC) e nos processos de implantação para garantir que o novo mecanismo seja integrado perfeitamente.

• Bases de código-fonte aberto e de terceiros — O uso de bibliotecas e componentes de código aberto de terceiros é comum. No entanto, essas fontes devem ser cuidadosamente gerenciadas e protegidas dentro do novo DevSecOps mecanismo.

• Código e artefatos reutilizáveis — Promover a criação e o uso de códigos e artefatos reutilizáveis pode melhorar a eficiência e a consistência, mas a propriedade e a governança desses recursos compartilhados devem ser claramente definidas.

• Repositórios e contribuições compartilhados — Permitir a autoria colaborativa de código por meio de repositórios compartilhados pode ser benéfico, mas requer um gerenciamento cuidadoso do acesso, das políticas de mesclagem e das revisões de código para manter a qualidade e a segurança.

• Estratégias de ramificação para IaC — A metodologia Git não é diretamente compatível com padrões comuns de design de infraestrutura. As estratégias tradicionais de ramificação talvez precisem ser adaptadas à IaC para acomodar os desafios exclusivos do gerenciamento da infraestrutura. Isso pode envolver o desenvolvimento de fluxos de trabalho especializados que considerem a natureza estável da infraestrutura, o potencial de deriva e a coordenação cuidadosa ao fazer alterações nos ambientes vivos.

• Gestão estadual — Gerenciar o estado da infraestrutura é crucial na IaC. O gerenciamento adequado do estado garante que a infraestrutura real esteja alinhada com o código definido e evite conflitos ou alterações não intencionais. A implementação de práticas robustas de gerenciamento de estado, como o uso de mecanismos remotos de armazenamento e bloqueio de estado, é essencial para manter a consistência e evitar conflitos em ambientes com vários usuários.

• Segurança - No contexto da IaC e DevSecOps, a segurança deve ser integrada em todas as etapas do ciclo de vida da infraestrutura. Isso inclui proteger a própria base de código do IaC, implementar controles de acesso com privilégios mínimos, criptografar dados confidenciais e verificar regularmente vulnerabilidades no código da infraestrutura e nos recursos implantados resultantes. As verificações de segurança automatizadas e as validações de conformidade devem ser incorporadas ao pipeline de integração contínua e entrega contínua (CI/CD) para garantir que as melhores práticas de segurança sejam aplicadas de forma consistente.

Projetar um DevSecOps mecanismo que capacite e apoie equipes diferentes de forma eficaz exige que você identifique todas as possíveis fontes de autoria de código e compreenda suas necessidades e desafios. Essa abordagem ajuda a garantir uma implementação e adoção tranquilas do novo mecanismo em toda a organização.

Projetar DevSecOps mecanismos vai muito além dos aspectos técnicos. O design e a implementação de DevSecOps mecanismos têm implicações de longo alcance. A equipe responsável deve considerar cuidadosamente os fatores culturais, organizacionais e humanos. Essa consideração ajuda a garantir que a solução não apenas atenda aos requisitos técnicos, mas também promova um ambiente de trabalho positivo, produtivo e envolvente para todas as partes interessadas. Encontrar o equilíbrio certo é crucial para o sucesso a longo prazo e a satisfação dos funcionários.

Considere os seguintes cenários relacionados ao projeto e à implantação de DevSecOps mecanismos:

• Ampliando a disparidade entre desenvolvedores e mantenedores — A implementação de um sistema que facilita a entrega rápida de soluções por desenvolvedores ávidos pode, inadvertidamente, destacar a aparente falta de trabalho dos mantenedores. Os mantenedores são indivíduos com títulos de desenvolvedor, mas suas day-to-day responsabilidades passaram para o suporte e a estabilidade dos aplicativos existentes. A falta de novas contribuições dos mantenedores pode ter sido menos visível historicamente. Essa situação pode fazer com que a organização subvalorize o conhecimento crítico e a experiência desses mantenedores, potencialmente causando ressentimento e um declínio no moral.

• Repelir desenvolvedores com uma solução excessivamente governada — Criar uma solução altamente governada DevSecOps que seja complicada para desenvolvedores ávidos usarem pode atrair mantenedores. No entanto, a solução pode afastar as pessoas de que a organização precisa para impulsionar a inovação. Forçar os desenvolvedores a aprender um mecanismo proprietário de CI/CD, além de seus aplicativos e linguagens de programação, pode ser uma barreira significativa para a adoção. Uma DevSecOps solução altamente governada pode se tornar um desincentivo para desenvolvedores talentosos.

• Correndo o risco de incompatibilidade e disrupção cultural — A implementação de um DevSecOps mecanismo que seja culturalmente incompatível com as formas existentes de trabalhar da organização pode criar atritos e resistências significativos. Se a abordagem do mecanismo (por exemplo, prescritiva em comparação com a consultiva) não estiver alinhada com a cultura da organização, provavelmente não será adotada. Como resultado, algumas partes interessadas podem ficar frustradas e acreditar que a organização está adotando uma burocracia desnecessária.