Early identification of issues – Implementing DevSecOps with AWS
- Blog
- Early identification of issues – Implementing DevSecOps with AWS
DevSecOps tooling automations can kick off as early as when the developer commits code to their local git repositories. By leveraging git’s pre-commit hooks, they can benefit from the feedback of these code scans even before they push the changes to a remote repository.
Tip
Trufflehog is one such tool that stops you from accidentally committing secrets into your source code. You can read more about this tool and how you can configure it as a pre-commit hook at https://github.com/trufflesecurity/trufflehog.
This controls any risk exposures that are introduced by recent code changes. The problems are easier to fix as the developers have a full context of what they were trying to do and the modifications are still fresh in their mind.
A defense-in-depth strategy also ensures that similar guardrails are applied and evaluated at multiple stages of the code development process. So, even if the local configurations on a developer’s machine are not functional, such risks can be mitigated at the next level, which could be a server-side hook configured in the remote repository management system, such as GitHub or GitLab.
An important aspect of DevSecOps that we have been discussing a lot is the cultural shift and change in roles and responsibilities. Next, we’ll discuss what this means for the different personas in a software team.
What it means for security professionals
Security colleagues have always been seen as some sort of gatekeepers and are ultimately responsible for any security risks that come up. As per DevSecOps methodology, this needs to change. Instead of resisting frequent code modifications and releases, they should act as enablers. The mantra for success for these professionals should be guardrails but not blockers. They need to continuously learn how DevOps works across the organization and evolve security processes by embedding the controls right into the DevOps methodologies.
Define security policies for both application and infrastructure
Security risks are now multi-dimensional. They apply to anything that is managed as code – so both infrastructure and applications. Security professionals should focus on defining the policies around what these code bases should and should not be allowed to do. Rather than dictating granular policies for each application or team, they should invest effort in establishing guardrails that protect the company and individual teams.
Introduce automated guardrails for policy enforcement
Manual assessments are a thing of the past. The policies should automatically apply to any workload that is deployed in the environment. AWS offers a lot of capabilities in this area where you can enforce detective, preventive, and proactive controls with the use of AWS Config, Service Control Policies (SCPs), and CloudFormation hooks, respectively.
© Copyright 2024 morningfun.org