Last year, a researcher reported a serious vulnerability in IBM i that could allow an attacker with minimal privileges to gain administrative control of the system, showing that even well-established, enterprise-grade platforms have security risks when secure coding practices aren’t followed.
SecureFlag’s new IBM i RPG labs are designed to help developers recognize these risks and prevent them through practical, hands-on training.
What Is RPG and Why Is It Still Used?
RPG (Report Program Generator) is a programming language developed by IBM, primarily used on IBM i systems (formerly AS/400). It was introduced in 1959 as a tool for generating business reports, but it has changed a lot since then.
Modern RPG, particularly ILE RPG, is built for the kind of complex business applications that large organizations depend on, supporting today’s development practices and integration with web services. Many organizations still use it to run business operations across finance, aviation, logistics, and manufacturing.
These systems are still in use because they are reliable, work well, and have become an integral part of business processes. It’s not easy to replace them due to cost and complexity. The problem is that this long lifespan comes with security challenges.
Risk in Connected Legacy Environments
When RPG applications were initially built, the threat environment looked different from what it is now. External exposure was limited, and security was mostly a physical and access-control problem, not a software one.
However, over the decades, these systems have been extended with new modules, integrated with web-facing applications, connected to cloud services and APIs, all without a proper security review.
Risks include:
-
Limited insight into input handling: Large, aging codebases can be difficult to audit, and it’s not always obvious where user-controlled data enters the system.
-
Assumed trust between systems: Legacy architectures often assume that anything coming from inside the network is safe, something modern attackers actively exploit.
-
Hardcoded credentials and tokens: Secrets embedded directly in application logic are a problem in codebases that predate modern secrets management practices.
-
Inconsistent secure coding standards: Security practices that are well-defined for Java or Python teams often have no equivalent guidance for RPG developers.
-
Poor integration with modern security tooling: SAST, DAST, and SCA tools rarely support RPG software, leaving teams without the automated safety nets they rely on elsewhere.
Also, because these systems are business-critical, change management processes are often slow, so when vulnerabilities are found, remediation can take far longer than it would in a modern stack.
What Do Security Issues Look Like in RPG?
The categories of vulnerability found in RPG are also present in other languages, and include SQL injection, insecure data handling, and logic flaws. What makes them dangerous in this context is how easily they go undetected and the impact they can have on critical systems.
Developers working in RPG may come across:
-
SQL Injection in embedded SQL: RPG supports embedded SQL, and queries that incorporate user input without effective controls are vulnerable to injection attacks.
-
Improper input validation: Procedures that receive data from external sources may not properly validate it before using it.
-
Sensitive data exposure: Credentials, tokens, or customer data showing up in system logs or message queues where they shouldn’t be.
-
Business logic abuse: Logic flaws that let users change outcomes, such as bypassing authorization or accessing records they shouldn’t have access to.
-
Overly permissive internal APIs: Internal interfaces that are exposed more widely without proper access controls.
Hands-On Security Training for RPG
SecureFlag’s IBM i RPG labs are built specifically to help developers through practical, scenario-based training rather than only reading theory.
Each lab places users in realistic scenarios where they review RPG code to identify security issues. The labs reflect how vulnerabilities are discovered in the field through penetration testing, SIEM alerts, code reviews, or incident investigations. For example:
-
Investigating how user-controlled input can change the behavior of embedded SQL queries.
-
Tracing how sensitive data ends up exposed in system logs or message queues.
-
Reviewing RPG procedures to identify insecure patterns and replace them with safer alternatives.
-
Understanding how business logic flaws can be exploited under specific conditions.
This hands-on approach gives developers practical experience identifying vulnerabilities in RPG code.
Supporting Secure Development Across the Stack
SecureFlag’s platform is built on the belief that secure coding training only works when it’s practical, realistic, and tied to the languages and environments developers work with.
For organizations running business-critical systems on IBM i, SecureFlag provides a way to bring the same standard of security training to RPG developers that modern application teams already benefit from.
As organizations continue to modernize, legacy systems will remain part of the picture, and they need to be as secure as everything else.
Ready to extend your secure coding program to IBM i RPG?
