Best practices - AWS Prescriptive Guidance

Best practices

When implementing a new DevSecOps mechanism, it's crucial to consider the various sources of code authorship and how they will be empowered or potentially blocked. Often, engineers may only interface with one of these sources. However, the introduction of a new mechanism can bring new authorship sources to the forefront or highlight challenges from sources not previously considered. Let's explore each of the following aspects in more detail:

  • Application team developers – These are the developers responsible for the core application code. They must be empowered to make changes and updates to the application code as needed, but their work must also align with the new DevSecOps mechanism.

  • Central infrastructure developers – This team is responsible for the organization's core infrastructure, such as cloud resources, networking, and security. They must be involved in defining the infrastructure as code (IaC) and deployment processes to make sure that the new mechanism is integrated seamlessly.

  • Third-party and open source code bases – The use of third-party libraries and open source components is common. However, these sources must be carefully managed and secured within the new DevSecOps mechanism.

  • Reusable code and artifacts – Promoting the creation and use of reusable code and artifacts can improve efficiency and consistency, but the ownership and governance of these shared resources must be clearly defined.

  • Shared repositories and contributions – Enabling collaborative code authorship through shared repositories can be beneficial, but it requires careful management of access, merge policies, and code reviews to maintain quality and security.

  • Branching strategies for IaC – Git methodology isn't directly compatible with common infrastructure design patterns. Traditional branching strategies might need to be adapted for IaC to accommodate the unique challenges of managing infrastructure. This could involve developing specialized workflows that consider the stateful nature of infrastructure, the potential for drift, and careful coordination when making changes to live environments.

  • State management – Managing the state of infrastructure is crucial in IaC. Proper state management ensures that the actual infrastructure aligns with the defined code and prevents conflicts or unintended changes. Implementing robust state management practices, such as using remote state storage and state locking mechanisms, is essential for maintaining consistency and preventing conflicts in multi-user environments.

  • Security - In the context of IaC and DevSecOps, security must be integrated at every stage of the infrastructure lifecycle. This includes securing the IaC code base itself, implementing least-privilege access controls, encrypting sensitive data, and regularly scanning for vulnerabilities in both the infrastructure code and the resulting deployed resources. Automated security checks and compliance validations should be incorporated into the continuous integration and continuous delivery (CI/CD) pipeline to ensure that security best practices are consistently applied.

Designing a DevSecOps mechanism that empowers and supports disparate teams effectively requires you to identify all of the potential sources of code authorship, and understand their needs and challenges. This approach helps ensure a smooth implementation and adoption of the new mechanism across the organization.

Designing DevSecOps mechanisms goes far beyond just the technical aspects. The design and implementation of DevSecOps mechanisms have far-reaching implications. The team responsible must carefully consider cultural, organizational, and human factors. This consideration helps to ensure that the solution not only meets the technical requirements but also fosters a positive, productive, and engaging work environment for all stakeholders. Striking the right balance is crucial for long-term success and employee satisfaction.

Consider the following scenarios related to the design and deployment of DevSecOps mechanisms:

  • Amplifying the disparity between developers and maintainers – Implementing a system that makes it easy for eager developers to quickly deliver solutions can inadvertently highlight the apparent lack of work of maintainers. Maintainers are individuals with developer titles, but their day-to-day responsibilities have transitioned to support and stability of existing applications. Maintainers' lack of new contributions might have been less visible historically. This situation could lead to the organization undervaluing the critical knowledge and expertise of these maintainers, potentially causing resentment and a decline in morale.

  • Repelling developers with an overly governed solution – Building a highly governed DevSecOps solution that's cumbersome for eager developers to use can attract maintainers. However, the solution might drive away the people that the organization needs to drive innovation. Forcing developers to learn a proprietary CI/CD mechanism in addition to their application and programming languages can be a significant barrier to adoption. A highly governed DevSecOps solution might become a disincentive for talented developers.

  • Risking cultural incompatibility and disruption – Implementing a DevSecOps mechanism that's culturally incompatible with the organization's existing ways of working can create significant friction and resistance. If the mechanism's approach (for example, prescriptive as compared to advisory) doesn't align with the organization's culture, it will likely not be adopted. As a result, some stakeholders might be frustrated and believe that the organization is moving towards unnecessary bureaucracy.