Shifting Security to the Left.

“Shifting Left” is the phrase used to describe performing security testing earlier in the development process. The objective is to move Security Testing as far inside the SDLC as possible.

To some organisations, shifting left simply involves performing the security testing in a dev / UAT environment before deploying into production. For others, it involves deploying SAST/DAST tools as part of a CI/CD pipeline and implementing “secure by design” concepts into workflows.

The concept of “Insecure Design” was introduced to the OWASP-10 as it’s own vulnerability classification in 2021, along with the following statement:

If we genuinely want to "move left" as an industry, we need more threat modelling, secure design patterns and principles, and reference architectures. An insecure design cannot be fixed by a perfect implementation as by definition, needed security controls were never created to defend against specific attacks. - The OWASP Foundation (https://owasp.org/Top10/**)**

The core philosophy behind shifting left is that security weaknesses that are caught early are much less likely to make their way into production systems, therefore represent a smaller risk, and are also much less costly to remediate in the long term.

Limitations to the shift-left approach are that it can be a burden on development teams, causing them to be less agile and dynamic. A move to left-centric security also discounts security controls that may be introduced later in the development process (such as firewalls and WAFs) which can often be a much more cost-effective means of mitigating some vulnerabilities than during initial development.

By understanding how controls later in the process may limit the impact of a vulnerability, it is possible to make judgements about the necessity of applying early fixes.

Found this article interesting, Read the complete research paper: Here