How Shift Left Is Implemented in DevSecOps

2017 may well be a watershed year for the hacker. It has now been reported that cyber criminals can utilize counterfeit TLS certificates to control Wi-Fi connections, giving them unlimited access to mobile device data. In light of these new developments, companies are increasingly compelled to shift left in terms of security.

Shifting left empowers software teams to detect operational breaches in every phase of the software supply chain, from design to deployment.

The stakes are high, but fostering a collaborative spirit between developer and IT security teams is key. Here are three ways to seamlessly integrate shift-left security into your company’s SDLC:

Empower developers to test their own code

Ideally, developers and software engineers should be familiar with fundamental security concepts. For the most part, security teams believe that the developer focus on coding minutiae and release datelines is misplaced.

Developers are similarly skeptical of security professionals who wield mysterious jargon and harbor markedly divergent attitudes towards security vulnerabilities. Thus, it is imperative that we empower developers to be able to test their own code. In doing so, we foster an atmosphere of understanding, which inevitably inspires collaborative effort.

One of the most important security concepts developers should have a minimal understanding of is the principle of “least privilege.” In DevSecOps, this is the practice of assigning privileged access to sensitive data within a cloud environment. Developers should understand why granular control of ”least privilege” policies and the corresponding concepts of sandboxing and honeypotting are essential aspects of the security toolbox.

While sandboxing contains untested code and sequesters it from the rest of an application, a honeypot  is a discreet virtual program that detects and repels unauthorized access to classified data.

Another important security concept is cryptographic agility. It is imperative that developers understand the potency and practical functions of cryptographic primitives such as cryptographic digests, symmetric/asymmetric key algorithms, public-key cryptographic algorithms. This is key to understanding how the secure storage of critical data fits into the shift-left methodology.

A third concept of interest to developers is threat modeling. This is the practice of identifying and analyzing architectural vulnerabilities and then designing focused countermeasures to annihilate potential threats. A deep understanding of threat modeling allows a developer to think like a hacker. It is a significant change from a shift-right security mindset to a shift-left mentality.

Astute CIOs will point out the upside of threat modeling to developers: the process targets the early or design phases of a project, which means that the possibility of re-designing conceptual frameworks during the later stages of the project is markedly reduced.

A successful integration of threat modeling into the developer experience involves identifying the client databases and code libraries to be protected. Developers will also need to analyze the components of an application such as trust boundaries, privileged code, and key attack vectors. A threat library with a rating system is crucial to identifying threat agent archetypes.

When developers can appreciate the implications of key security concepts, they are empowered to understand the “secure from the start” nature of shift-left methodology. In this vein, companies are showing an increasing inclination to pay for secure coding training for developers, believing that it is an investment well spent.

Train testers to understand the fundamentals of coding

When we train testers to code, we ultimately facilitate efficacy at every stage of the shift-left testing process. Testers can spot discrepancies in code and make minor alterations without burdening already time-constrained developer teams. However, there is no consensus as to whether testers need to learn how to code.

Detractors argue that testers who learn how to code might as well be programmers. They proclaim that testers who code may be tempted to spend inordinate amounts of time modifying their code rather than testing it.

Meanwhile, proponents argue that testers rarely need to develop high levels of coding proficiency; they merely need to acquire a working fluency in coding fundamentals to facilitate meaningful dialogue with developers.

Within the shift-left paradigm, testers who acquire code comprehension capabilities gain crucial perspectives that can only affect their interactions with developers positively. The powerful shift-left approach can be successfully implemented by embedding testers in developer teams.

Leverage the power of Kiuwan SAST, especially Kiuwan for Developers

The ideal way to implement shift-left in DevSecOps is to equip your developers with the ability to perform source code analysis through SAST (Static Application Security Testing).

Kiuwan SAST for Developers analyzes source code from the insider’s view and is implemented early in the development phase, which means that it analyzes code early in the SDLC, a typical asset in shift-left testing.

By deploying the Kiuwan IDE plugin or Local Analyzer, developers can identify pertinent source code vulnerabilities within the IDE itself. The code is automatically analyzed when it is saved. Automatic scanning of code modifications guarantee that complications are discovered and rectified before the application is deployed.

Kiuwan’s code review badges allow members of developer teams to identify (at a glance) how secure the source code is. The “security badge” displays the type of vulnerabilities that have been correctly identified and counteracted, while the “quality badge” shows the overall quality level of the code.

SAST is intrinsically well-suited to an agile, shift-left environment and as an automated testing solution, is exceptional in its ability to address every stage of the continuous integration process. For example, while other SAST tools fail to identify cryptographic-related attacks, Kiuwan is a leading industry expert in nullifying the detrimental effects of such threats.

Kiuwan SAST also supports multiple languages (including mobile application languages) and environments. Currently, Kiuwan ranks #1 on the OWASP benchmark, detecting SQL injection attacks, trust-boundary violations, broken cryptographic algorithms, XPATH and LDAP injections, and buffer overruns.

As a SAST provider, Kiuwan returns an almost 100% true positives rate (TPR) on the OWASP benchmark, a phenomenal accomplishment in the cyber-security industry.

A shift-left approach has become more necessary than ever in a changing world. As can be seen, implementing such an approach need not be an intimidating process. Start by implementing the 3 suggestions above, and you’ll be on your way to greater application security.