One of the recent initiatives to maintain the improvement velocity at Emyode was to look into the integration of SecDevOPS into the workflows to include code quality inspection.
Since one of the aspects of SecDevOPS is to ensure that good practices are maintained and enriched in time, the addition of a code quality control tool would certainly be a move in the right direction.
The rationale behind this is establishing some standards that can be used “enterprise-wide” as to the expectancy of code quality. Also, the process of establishing the rules of code quality can be a multi department interactively decided standard. Wherein the center of excellence and the dev teams establish some additional standards, beyond the industry baseline, some added rules would be a benefit.
It is, in essence, having the benefit of the devs experience with the mistakes of the past, to ensure the future is free from the situations that they have already encountered. Hence a part of continuous improvement.
Where this fits in the DevOPS tool chain is at the gated check-in time or in the continuous integration step. There, in addition to the unit testing, you can add a step to establish a threshold of code quality in order to ensure that the quality of the added code hasn’t degraded the product.
Furthermore, the threshold can be adjusted, in time, to improve code. This means that the organisation can create a roadmap to how they want to improve the standards over time and lower the tolerance for certain aspects of the code that they find substandard.
There are two important aspects of security in the ideology that is SecDevOPS, as we see it at Emyode.
The first is to set a way of doing things that prevent degradation in time. In other words, it is about giving visibility on how we make things better and maintaining this direction towards improvement, as an ongoing thing. This aspect of implementation of “securing” the process, as the improvements go forward, is much easier to do when inspecting and controlling the actual code standards than during functional testing. It is about diminishing the risk to a vanishing point, where the value of the work could be compromised in the future.
Secondly, adding a layer of security ensuring that in the code, the typical security errors (properly speaking) are not present. This is not surface penetration testing, to be sure, but verifying that your SQL statements do not include wildcards, for example, or that IP addresses aren’t hardcoded in the application. Where injection could happen, it can be detected, reported and caught, for instance, same for buffer overflows or bad hashes. Essentially, it is about adding yet another layer of security, one with the vulnerabilities or compromise of the data in mind.
In the Toolchain
At Emyode, we like horizontal integration. It is part of how we manage teams and processes. In this regards, Microsoft’s Visual Studio Team Services (VSTS) is unmatched. From design to delivery, all of the work can be traced back and forth with a web based interface. The ultimate in visibility. So how do we add this new feature of code analysis?
One of the great features of Microsoft VSTS is the ability to use extensions. These extensions add power to the existing toolchain, adding new tools to it, without compromising the existing process. One such extension allows the integration of the open source tool SonarQube to the build steps.
The process of adding this extensibility is very simple. And once this extensibility is added, it is possible to set rules, shared between projects or segregated as needed. These rules can cover anything between style and vulnerabilities. Each rule can affect the score of the code quality, to which a threshold can be set as quality gates thus, code promotion can pass or fail depending on the set rules.
We truly believe that SecDevOPS is an essential part of continuous improvement at Emyode. With the added value of ensuring that the quality of our work is always moving forward and keeping the process lightweight by using SonarQube, and seamlessly integrating in the build process. Not only you can set a pass/fail grade to your code, but you can also view a complete analysis of it, with rules scores over time. There is much more to make a SecDevOPS a permeated principle in an organisation but at Emyode we believe this method is a prominent way to start with a minimum of risk.