Three Things For IBM i Shops To Consider About DevSecOps

October 13, 2025 Michel Mouchon

Way back in the Great Recession, when money was getting tight and the technical debt was getting high, the concept of agile infrastructure evolved into DevOps, the synchronization and coordination of application development, which likes to move fast, with IT operations, which likes to have things running in a stable fashion. The idea runs counter to half of the philosophy of Facebook founder Mark Zuckerberg, who has espoused the principle to “move fast and break things.”

DevOps wants to move fast, but it most assuredly does not want to break things, and many millions of programmers and operations staff at the enterprises of the world have learned to work together in a single continuous integration/continuous deployment workflow that is more encompassing and a lot more useful than the software change management that large enterprises started deploying to automate some aspects of their software development in the 1970s and with growing momentum in the 1980s and beyond.

It wasn’t long after the DevOps movement took off in 2008 through the efforts of Andrew Clay Shafer (one of the co-founders of Puppet) and Patrick Dubois, and it wasn’t long before Shannon Lietz (who was at accounting software maker Intuit at the time) was talking about DevSecOps, correctly putting security right in the center of the DevOps movement and the tools that embody it.

It is a decade since that DevSecOps movement started, and maybe somewhere on the order of 3,000 IBM i sites worldwide – usually from highly regulated industries like healthcare, banking, finance, and insurance. Maybe an order of magnitude more IBM i shops are using third party application software and have, in essence, outsourced the DevSecOps problem. But the rest of the IBM i base – which means most of the customers using the Power Systems platform running the IBM i operating system – not only needs DevOps, but they really need DevSecOps and they need to understand why.

The first thing to consider is that companies need to make their code secure – and keep it that way.

This means, for instance, not allowing programmers to generate a possible breach inside the code, like an SQL injection or whatever. But with IBM i specifically, you have the capability to do override of the user profile. There is an API that could be used to launch commands with the power of what we call adoption, and this adoption could be a really big bridge into the vulnerability. That’s why we have ARCAD CodeChecker, which checks the code regarding rules of coding and policies of security in terms of coding.

Which leads to the second thing: Having the right CI/CD process provides security because you are always following proscribed processes and not doing something that is not “normal” and can therefore inadvertently introduce risks and security vulnerabilities into the system.

Here is an IBM i-specific example. Say an application uses some APIs on IBM i, it must be done under a strong security regimen. Deploying a set of components on the system, for example, requires a certain level of authority for doing that, because you have to remove a program and replace it by another one. You can understand that this also introduces a potential vulnerability. It is important, as you can see, to ensure that the automation that does this process is also secure. It is not just about having the network secure and having the right level of security settings for objects in IBM i.

Here is a good analogy from the world of logistics and transport to make this idea clear. When you load a bunch of boxes on a pallet, you have to ensure that you put the right things inside the boxes when you sell them. But during the many legs of transportation, if someone can pull over the truck and open the box on the side of the road, potentially take things out or replace it with other things, you have generated a risk.

So whatever process and whatever automation you use for applications through the whole DevSecOps process has to be secured – and known and verified continuously to be secured – from the first line of code a developer types to the first second an end user uses that function in production. This is what the ISO 9001 quality management system standard, which is applied across all kinds of business functions, is all about. To get something well, and keep it well.

Here is the point: even if you have secured all your processes inside the network, you open the door to the outside world. It must be secured sufficiently to ensure the end-to-end transportation of packets. But if you have a very secure network, but anybody can put a USB keychain into their on the laptop and introduce something, anything, into the network, you have a vulnerability. I am the CISO at ARCAD, and I can say we see attacks on our network every few seconds or every few minutes, depending on the day. Your process has to be diligent and vigilant.

A welcome side effect of application modernization, by the way, which ARCAD automates with our Transfomer range, is that through auto-refactoring we make the applications and therefore the systems more secure. It is easy to put malicious code into big programs. It just makes sense to say that the more the modular your code, which makes it easy to maintain is also making it easier to protect because it is easy to do unit testing and regression testing against the modules. You will do it on code more often, too, and it will be more difficult to introduce malicious code from the outside.

This brings up the third consideration of DevSecOps: the security of the data itself.

In our regression testing tool, ARCAD Verifier, we do not just check the code, but we also check the data – not just the bits themselves, but the order in which data was accessed and modified, and the user interface screens, too. But data security goes beyond this. Whenever you extract data from production databases to populate a test environment, that data needs to be anonymized irreversibly to avoid any risk of personal data leak – while at the same time preserving the nature and consistency of the data so that tests remain realistic. Our DOT Anonymizer automates this process, across multiple DBMS. Even the extraction process is automated, using DOT Extract, our subsetting tool.

You have to protect the code, protect the process of developing, deploying, and maintaining the code, and protect the data that the code uses. Doing any two of these is necessary, but it is not sufficient.

Join our Webinar to learn more: IBM i DevSecOps and Peer Review – the Power of Automation

Michel Mouchon is chief technology officer and also chief information security officer at ARCAD Software.

This content is sponsored by ARCAD Software.

This Issue Sponsored By

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search