DevSecOps for IBM i

Digital transformation and large-scale cloud adoption have seen software become the primary cause of business and operating risk. Complex application architectures involving interactions between multiple technology layers have grown the attack surface for many software systems. New computing paradigms such as serverless computing, API-first and microservices have evolved rapidly and not always with security as foremost design principle.

At the same time, the software industry has seen DevOps techniques introduce new efficiencies to software delivery. Yet these accelerated development cycles often fail to detect security flaws in a timely manner – contributing to overall security risk. Unforeseen vulnerabilities lie dormant in hastily developed code and the libraries it is built upon.
DevOps has also changed the way security is managed. Traditionally security verification has been a distinct phase performed towards the end of the software development lifecycle by a dedicated team. However, in modern DevOps implementations this siloed approach can be a source of conflict. To prevent a bottleneck in delivery, security must become be a continuous concern, a shared responsibility between all actors involved, across development, QA, operations and information security teams.

Faced with new risks of digital transformation and ‘always on’ cloud environments, security shifts left into software creation – security by design, not an afterthought. As we infuse security into the DevOps cycle, we achieve DevSecOps.

Behind every successful DevSecOps implementation is automation. Most security breaches today are due to human error. Manual peer reviews risk leaving coding flaws undetected. Manual and sporadic testing allows vulnerabilities through to production environments. Ad hoc deployment and patching fail to catch insecure software at the most critical point in the cycle.

To minimize risk, each successive phase in the DevSecOps cycle must be automated and continuous. By automating a series of secure quality gates, we ‘shift security left’ and prevent expensive rework.

The IBM i is one of the most secure platforms ever made for business. It has five progressively impenetrable levels of security built deep into the operating system.

So why would IBM i need DevSecOps principles at all? As IBM i applications are modernized and integrated with external apps and devices, traditional legacy code is exposed as Web services, creating a whole new set of risks such as SQL injection and unsafe APIs. To catch these new threats, DevSecOps teams rely on static code analysis techniques that apply quality control rules such as those recommended by the OWASP community.

Also let us not forget that insider threats account for anywhere from 60 to 75 percent of data breaches. Even the most secure business system relies on automated data anonymization techniques to mitigate risk and prevent unauthorized access to sensitive data.

Many DevOps implementations have been built by weaving together loosely coupled non-integrated ‘point’ tools. This makes it far harder to measure quality and security levels and manage risk. The saying you can’t manage what you can’t measure” applies as much to security as to any aspect of software development.

To achieve compliance in today’s hybrid environments DevSecOps teams need a holistic view of security, from application analysis through to deployment, spanning multiple technologies and platforms. This can only be achieved with an integrated toolset, a shared repository and a single point of reporting and control.