Beyond Source Control: Verifying IBM i Bill of Materials for DevSecOps Integrity 

DevSecOps on IBM i: Securing Object-Level Integrity Across Environments

In the world of IBM i, application ecosystems are vast, complex, and deeply integrated. Unlike distributed systems, IBM i applications comprise thousands of discrete objects—programs, data areas, files, service programs, and more—distributed across multiple libraries and environments, including development, test, and production. Managing the integrity, synchronization, and security of these objects is essential for operational continuity and regulatory compliance.

Understanding IBM i Objects and Dependencies

IBM i applications are fundamentally object-based. Each object performs a specific function, resides within a library, and carries attributes such as ownership, authority, and dependencies on other objects. For example, a program object may depend on a service program or database file, which must be at the correct version for the application to operate properly.

Because these objects are deployed as binaries—and not dynamically built from source at runtime, as in many distributed systems—it’s especially important to track and verify the correct versions of all objects across every environment.

The DevSecOps Challenge

Operational and development teams must work in concert to ensure IBM i objects remain consistent across development, test, and production. Without a coordinated DevSecOps process, it’s easy for objects to fall out of sync: outdated binaries, incorrect authority settings, improperly compiled dependencies, and unauthorized changes can introduce operational risks.  

These discrepancies can cause application failures, security vulnerabilities, audit findings, and financial impacts.

The risk escalates when emergency fixes are applied directly in production. While often necessary to resolve urgent issues, this practice circumvents formal change control processes, source code repositories, and audit trails. When these changes aren’t retrofitted to development and test systems, environment drift can persist undetected.

In the worst-case scenario, production environments could be compromised by malicious changes. Since IBM i objects are not rebuilt from source during deployment, a bad actor with access to production could inject malicious binaries that remain invisible to standard source code reviews.

Securing the DevSecOps Pipeline

An effective DevSecOps strategy for IBM i requires more than source control—it demands comprehensive object-level governance. Key practices include:  

• Object-Level Tracking and Verification: Implement tools and processes to track objects across environments, verifying that production binaries precisely match what’s defined in source control and development environments.
• Audit-Friendly Deployment: Adopt promotion workflows that log what objects are deployed, where, when, and by whom.
• Environment Synchronization: Ensure that emergency fixes are captured, documented, and retrofitted into development and test environments to maintain alignment.
• Authorization Management: Regularly audit object-level authorities to identify excessive privileges, improper ownership changes, and potential security risks.

Why Object Integrity Matters

Even with a documented bill of materials (BOM) for each release, having a list of expected objects is not enough. You must confirm that the actual objects running in production match those intended from development and source control.

Discrepancies can result in audit failures, operational inconsistencies, and—in the most serious cases—business disruption due to malicious code execution.

The consequences of a failed audit are significant: regulatory penalties, reputational damage, operational delays, and financial loss. Organizations may be forced to halt deployments, revalidate systems, or suspend operations until compliance is restored.

Bridging the Source Control Gap

In IBM i environments, DevSecOps isn’t just about pipeline automation—it’s about preserving integrity and trust across every environment, one object at a time. Popular version control systems like Git, while excellent for managing source code, do not natively handle IBM i’s object-based architecture. They lack the ability to confirm whether the object deployed in production was built from the source in the repository.

This gap highlights the need for additional, IBM i-specific verification tools and processes to maintain operational trust and compliance.

Conclusion

DevSecOps success on IBM i depends not only on automation but on rigorous, continuous verification of object-level integrity across development, test, and production systems. Because IBM i applications are built and deployed as binary objects—often independent of source repositories—traditional source control tools alone are insufficient to guarantee production fidelity.

 To safeguard against compliance issues, security threats, and operational disruptions, organizations must adopt object-aware DevSecOps practices. This includes thorough tracking, audit-ready deployment processes, proactive environment synchronization, and diligent authority reviews.

Ultimately, effective DevSecOps on IBM i means verifying what’s actually running—not just what’s documented.