What Role Does Developers Play in Building Digital Trust?

If Anyone Can Inspire Digital Trust, It’s Us – Developers

ALBERT OOI

Lead IT Architect, Applications Services, NCS Group

In the world of big data and Artificial Intelligence (AI), digital trust underpins continued growth and development. However, building a strong, reliable, safe and secure digital trust ecosystem is no easy matter. No free rider is allowed – regulators, tech companies, consumers, and at the heart of it, ethical DevOps are all essential.

But with everyone in DevOps talking about being agile, and failing fast and learning fast today, where does quality stand? How can we strike a balance between speed and quality? Or what measures can we put in place to harmonise them?

IT ALL STARTS WITH SECURED AND QUALITY SOFTWARE

Typically, two approaches are most commonly applied in ensuring software quality – do quality checks after the design and development cycle, or continuously throughout the development phase. While the former is a common practice traditionally, the latter typically offers fewer problems and surprises at the end.

WHY SECURITY SHOULD NOT BE AN AFTERTHOUGHT

By starting small, chewing little, validating, testing and then progressing a little more, it fits the ideology of fail fast and learn fast. And even when nothing fails, insights gained can help optimise long term goals, and move the development along. In a nutshell, this is shift left security.

Contrast this method with waterfall monolith applications where testing is only conducted at the end. Not only is it likely that we will end up with a long list of issues that need fixing, we may also have to redesign modules or patch in complex workarounds to resolve issues that could have been circumvented totally if checks were conducted earlier.

That’s not a great way to design – obviously.

THE CASE FOR SHIFT LEFT SECURITY

You’ll ask – what then is a better approach for DevOps? Well, take a Jenkins build pipeline that churns out software sub modules. We’ll want to embed quality checks into every pipeline processing each software sub module and deal with arising issues incrementally instead of having a surprise when codes are assembled and run. Try imposing this concept into a manufacturing line setup that runs from left to right. Quality checks should be implemented as much left as possible and practical before the final code assembly comes – in other words, shift left the quality checks. If issues can be detected early, they can be fixed early. Importantly, costs of rolling back major design decisions and architecture rebuild can be avoided.

HOW TO MAKE SHIFT LEFT SECURITY WORK

Shift left security sounds great in concept. But, how well the development team embraces it will depend on the pipeline design. Do we design code build, scan, test and deploy into a single pipeline? Definitely not – else every build will take hours if not days to run.

Developers are keen to find out if the code they build integrates well with the rest, and that needs to be done as often as possible – preferably once a day based on a trunk approach. Therefore, breaking up build, scan, test and deploy into respective pipelines is the best way to allow developers flexibility to increase the velocity and efficiency of the DevOps process. Depending on how long scans or automated testing runs are, weekly or even longer batch jobs can be scheduled to accommodate that. Other determining factors include how fast codes are generated and how large the development is.

By now, it should be clear why adopting shift left security in code development is preferred – from more efficient software rollout to alleviating security domain issues. Moreover, commercial and open-source tools are readily available in the market to help us with its implementation. For your easy reference, I’ve listed examples in various categories in the box.

SECURITY AND CODE QUALITY TOOLS

For General Code Quality and Static Code Vulnerability

Source code is examined to check for duplicate codes, complex ifelse while loops, its maintainability, the design of naming conventions, vulnerability to the OWASP and CWE threat list.

Recommended tools:

Sonarqube, Fortify SCA, CheckMarx, Appknox, Snyk, and CodeScan.

For Dynamic Vulnerability Scans

Also referred to as black box scans done from outside in, the scan is performed on the runtime with deployed binaries. The tools will crawl through various application inputs and responses and try to expose vulnerabilities.

For Dependency Libraries Vulnerabilities

Dependency open-source libraries used by DevOps applications can be vulnerable to security issues so scanning for OSS vulnerabilities is critical as they have a large attack surface and most organisations do not have a good system for vulnerability tracking and expedient updates. This scanning process, also known as software composition analysis, scans each OSS library.

For Container Security

Container security tools provide close signature monitoring of container drifts and rogue containers, scan for container setup errors and vulnerabilities, and provide risk scoring for each vulnerability by taking into account metrics such as whether the container has internet connection, open ports and attached security profiles. These tools also provide trusted image feature controls to check that specific image registries and even specific images are used.

Recommended tools:

Fortify Webinspect, OWASP ZAP, Netsparker, Appscan, CheckMarx, and Acunex.

Recommended tools:

Nexus Lifecycle, OWASP Dependency Check, OSIndex, Snyk, and Gemnasium.

Recommended tools:

Aqua Security, Twistlock, Claire, Docker Bench, Anchore, and Trivy.