Secure by Design: How DevOps Security Transforms IBM i Development

Do you know with certainty what code you actually have running in production? Does the source location match the location identified in the object description? Are you really aware of what changes are being made to the code and whether that code is protected from potential security vulnerabilities? Implementing proper IBM i DevOps security practices is essential for protecting your systems from vulnerabilities. 

Over the past 30 years, I have been involved in thousands of implementations of software change control tools in the IBM i world and the one consistent thing I can count on is that I will always find objects whose source is not in the place in which the object description says it is. I have even seen change management systems that compile programs to temporary libraries, copy the source and object to the actual production libraries and then patch the object description to reflect the current location of the source and objects. That means that there are production objects running in most IBM i shops for which no one really knows what they contain. Many IBM i shops can’t recompile large swaths of their applications because things might stop working – a symptom of not truly knowing where the correct source code is.

I have also found that most source code change processes rely on trustworthy developers (Fortunately, I have found that the vast majority of IBM i developers fit that description). However, unfortunately, I have also found exceptions to that rule. I once worked with a casino in Nevada whose IT director managed to embezzle five million dollars by burying his nefarious deeds in the programming code.

As one CIO recently told me, “We’ve spent years hardening our IBM i applications and implementing robust authentication, but we just realized our development pipeline has almost no security controls. Anyone who gains access to our source code could potentially inject malicious code that would bypass all our other security measures. And, as we are exposing more of our application to outside connections, we don’t have consistent processes to check our code for vulnerabilities to attacks.

In my conversations with IBM i development leaders over the past month, one theme continues to emerge: organizations have invested heavily in application security while neglecting the development processes that create those applications. This disconnect creates a significant vulnerability gap—one that modern DevOps practices are designed to address. 

This realization represents a critical shift in how we think about IBM i security. It’s no longer sufficient to focus solely on the security of the finished application. True security requires addressing the entire development lifecycle. 

The Hidden Vulnerabilities in traditional IBM i Development

Traditional IBM i development approaches often lack the security guardrails found in modern DevOps practices. This creates significant exposure to vulnerabilities, compliance issues, and technical debt that can compromise even the most secure applications. 

Some of the most common security gaps I’ve observed in IBM i development environments include: 

1. Limited Code Reviews – IBM i shops are often so resource constrained that they can’t get a second set of eyes on changed code. This creates both potential quality issues and security vulnerabilities. It also means that there is usually just one developer who understands the changes.
2. No Approval Processes – Many IBM i shops simply allow programmers to move their changes into production without any additional authorization. This can result in surprised end users who were unaware of the incoming changes but it also creates a vulnerability should a developer’s credentials get compromised.
3. Lack of automated code scanning – Without tools to automatically identify security vulnerabilities, insecure coding practices often go undetected until they reach production.
4. Programmers with *ALLOBJ authority or Unlimited Access to Production – Many IBM i shops grant programmers more authority than they should have. This dramatically increases the danger if a developer’s credentials get compromised.
5. Insufficient dependency management – Before a change is made, it is important to review the list of objects that might be impacted by the change. This avoids production surprises. In addition, many IBM i applications incorporate open source components, yet few organizations track these dependencies for security vulnerabilities.  
6. Undocumented deployment procedures – Manual, undocumented deployment processes create opportunities for malicious or accidental security compromises. 

Transforming IBM i Development with Modern DevOps 

The good news is that implementing secure development practices doesn’t have to slow down your development process. In fact, modern DevOps approaches can enhance both security and velocity simultaneously. 

Enforced Code Reviews: The Foundation of IBM i DevOps Security

While many IBM i shops have informal code review processes, modern DevOps takes this further by making code reviews mandatory and providing tools that make reviews more effective. 

By implementing pull request workflows in systems like GitHub or Azure DevOps, organizations can ensure that all code changes are reviewed before they’re merged into the main codebase. The pull request process will prevent a promotion from occurring unless the appropriate approvals and reviews have been done. These systems also provide auditable records of who reviewed the code and what changes were requested. 

Automated Code Scanning for Enhanced IBM i Security

Tools like SonarQube can now scan RPG, COBOL, and other IBM i languages for security vulnerabilities, providing immediate feedback to developers. One manufacturing client recently integrated SonarQube into their development process and was astonished to discover dozens of previously unknown SQL injection vulnerabilities in their code base. 

The key advantage of automated scanning is that it provides continuous feedback without slowing down development. Vulnerabilities are identified early in the development process when they’re easiest and least expensive to fix. 

Dependency Management 

Open source components have become increasingly common in IBM i development, yet many organizations lack visibility into the security implications of these dependencies. 

Modern DevOps practices include automated tracking of all third-party components and immediate alerts when vulnerabilities are discovered in these dependencies. This approach enables teams to quickly identify and update vulnerable components before they can be exploited. 

Minimum Required Access Authorization

IBM i users should be granted the minimum access they need to perform their duties. The move-to-production process should be tightly controlled and done by a strictly limited number of authorized users. Ideally, the process should be initiated automatically by your DevOps system only after all required approvals have been gathered. Only the DevOps system should have the ability to update production. (For even better security, that same process should be in place for intermediate test environments).

Secure Deployment Workflows 

Traditional IBM i deployment processes often rely on manual steps and excessive privileges, creating opportunities for security breaches. 

Modern DevOps practices implement automated deployment pipelines with strict access controls. These pipelines ensure that only approved, tested code can be deployed to production, and they maintain detailed logs of all deployment activities for audit purposes. 

Version Control Security 

The source code repository itself is a critical security control point in any development process. Modern version control systems provide powerful security features that many IBM i shops aren’t fully utilizing. 

These features include signed commits (which verify that code changes came from trusted developers), branch protection rules (which prevent unauthorized changes to important branches), and detailed audit logging of all repository activities.

Real-World Implementation 

These concepts may sound abstract, but they’re being successfully implemented at IBM i shops today. A financial services client recently transformed their IBM i development process by: 

1. Migrating their source code from traditional IBM i libraries to Git 
2. Implementing mandatory code reviews through pull requests 
3. Setting up automated scanning of all code changes 
4. Creating secure deployment pipelines with appropriate access controls 
5. Implementing branch protection rules to prevent unauthorized changes