Developers require the support of security processes and tools that allow them to create without having to slow down for security compliance in order to ensure that shift left practices are effectively implemented. Adding regulatory compliance to the shift left process will only slow down release cycles by causing onerous review processes for both security and development teams.
Recent high-profile supply chain attacks have highlighted the need for more open-source community regulation. President Biden’s recent executive order in the United States, for instance, requires government vendors to attest “to the extent practicable, to the integrity and provenance of open source software used within any portion of a product.” The president’s new order, as well as potential legislative responses, could result in burdensome regulations that impede shift left practices and, as a result, hinder software development.
The problem with the directive is that almost all software developers have very little secure code training. Traditionally, developers have been focused on releasing creative, stable products rather than triaging security concerns. They want to employ open-source code without considering the security implications. Open-source components are used by developers because they are ready-made pieces of code that allow them to meet competitive release deadlines. They frequently entrust the detection of errors to their security teams towards the end of the development phase.
Also Read: Addressing the Growing Skills Shortage in Cybersecurity Industry
Security teams vs. developers
The security teams’ cautious attitude is frequently challenged by developers’ reliance on open-source components. Only 31% of companies report having agreed upon prioritizing methods between developers and security professionals about according to a 2020 WhiteSource report “Security vs. Developers: The DevSecOps Showdown.” Many software organizations even have separate guidelines for security and development. Because of the divide between the teams, security experts frequently purchase application security products that ignore the needs of developers.
In order to meet deadlines, both developers and security professionals admit to feeling pressured to “tick the box” on security measures. As a result, security is frequently sacrificed in order to speed up development, allowing hackers to exploit flaws in open source programs.
Shifting left can bridge the gap
The shift left strategy bridges the gap between developers and security professionals by bringing security testing and vulnerability management into the development process as early as possible.
All testing, feedback, and changes are performed constantly during the development process in a shift left model. This allows businesses to spot security flaws in their software early on, before they become more time-consuming, complicated, and costly to address.
Will shift left practices be hampered by regulation?
Many organizations do not have a fully matured the shift left approach, supported by an application security program. New open source regulations could exacerbate the problem by creating too many rules and liabilities for identifying vulnerabilities — rather than resolving them. Extensive regulation can add too much noise to the vulnerability management process, slowing the remedy process in the end.
While application security tools help security and development teams in addressing security and open source license compliance early in the development process, most won’t be up to the task of dealing with additional regulations, which will necessitate in-depth legal assessment.
Also Read: Effectively Implementing Zero Trust Principles to Accomplish Enterprise Security Goals
Consider what it would be like if developers and security experts had to put their projects on hold on a regular basis while their legal departments checked to see if all of the open-source components they were using complied with regulatory requirements. Any shift left processes currently in place would be undermined by this practice.
Many software companies will almost certainly postpone more regulatory reviews until the end of their development cycles. Developers and security teams could spend hours dealing with compliance issues instead of producing and releasing products if the legal department finds issues.
For more such updates follow us on Google News ITsecuritywire News. Please subscribe to our Newsletter for more updates.
