DEVOPSdigest

Those of us in the software world know that typical Software Development Lifecycles (SDLC) are sequential — not to be confused with linear. In other words, there are "steps" or phases to each development stage. With each stage there are controls and safeguards, as well as a review of policy regulations, before moving to the next step to ensure quality, security, and performance.

This is important, because if a certain control is done too late in the cycle, the resources wasted backtracking to remediate errors can be extreme — sometimes in the order of 10x when compared to the resources spent detecting errors in advance.

For this reason, it makes sense for organizations to shift-left any and all development processes it can, while also making it technologically feasible. The market has already shown these movements, and technological advancements are currently in place to shift-left for monitoring and testing from a quality perspective. It is only recently, however, that we're also seeing the same directional change for security.

Organizations, not surprisingly, are once again looking for technological advancements that will allow them to shift-left security. This would include the ability to execute security policies in code or during build time, and for security engines that are smarter and more effective when looking at source code.

The challenge is that not all tools and processes work in a shift-left world. Tools and processes that were created "in the right" side of the process are often built purely for production environments, relying on central processing and management, and have security oriented professionals operating it rather than developers. While many security tools try to shift-left, they fail to do so in a complete, seamless manner; often the integrations are clunky, or the tool only partially solves the shift-left intent early in the SDLC. This is where the concept of "developer first" plays a role.

Developer first means the tool or process was built from the ground up with developer input from inception. It takes into account tool properties and attributes such as speed and integration with developer tools first rather than production tooling.

For instance, developers typically require tooling to run on a multitude of development environments, from OS to virtualization, and to container platforms such as Docker, Kubernetes and their respective ecosystems, such as Helm and others. These developer-first tools must act as a guide or "advisor" with just-in-time coding information and insights. They must also be very informative in the continuous integration build process, which requires faster analysis and feedback cycle and specific formats of reports to support. Configuration and pluggability must be made throughout the command line, APIs, and local configuration, which helps streamline into the SDLC rather than a central management system and UI.

Being a first-class citizen in security as code (SaC) is important, and developer-first security tools are built from the ground up to understand security policies that are co-located with code. They also configure and execute locally to a specific SDLC pipeline or to all pipelines in the organization, providing a high degree of freedom for the practitioner for refining results, policies, and rules as they code. In order to function correctly, developer-first security tools must be implemented properly. Likewise, it's crucial to pick the right tool when going for a shift-left process.

Once again when it comes to shifting left, we've witnessed similar movements in the worlds of testing and monitoring tools. It started with Selenium and JMeter, which were completely "shift-right" tools that shifted left successfully, but ultimately did not have the developer experience and the ability to move fast with the developer. Consequently, these tools were quickly superseded and taken by a storm of others such as Puppeteer and Cypress which are great developer-first testing and monitoring automation tools.

When looking to shift-left security, it is important to understand these nuances in order to better protect your environments and to create frictionless experiences for your developers. Additionally, organizations should make it a best-practice getting your development and security teams working together at the outset of any SDLC.