An IBM i security audit produces a stack of reports about objects. It lists the user profiles carrying all-object special authority and the public authority sitting on production libraries. It names the exit programs registered against your network servers and the files your team journals.
Every one of those reports reads the system as it sits right now. Then the auditor asks a question none of them answer. Which programs read the account number, and what authority are those programs running under while they do it?
That answer lives inside the RPG source. Your security tooling has never opened it.
What an IBM i security audit measures, and where the report stops
A standard IBM i security review covers a known list. It checks system values against a hardened baseline. It inventories special authorities and finds the profiles that collect them. It reads public authority on libraries and objects. It confirms that auditing runs and that somebody keeps the audit journal.
That work is necessary and your team should keep doing it. It also has a boundary, and the boundary is easy to state. Those reports describe objects. A program is an object with an owner and an authority list, and it is also a body of logic that somebody wrote in 1993.
Your system documents the object half completely. Nothing on the system documents the logic half. An AS/400 security audit that stops at the object half answers who can run a program. It never answers what the program does once it runs.
Four questions an auditor asks that the object report cannot answer
These four come up in banking, insurance, manufacturing and government reviews with enough regularity to plan for.
- Which programs read or write the regulated field, and which of those programs run in batch with no user attached?
- Which programs adopt their owner's authority, and what does that borrowed authority reach?
- Where does the source hold a user ID or a password in plain text?
- Which interfaces move regulated data off the system, and what starts them?
Each question has a factual answer. Each answer sits in a source member, and your team can produce all four without changing a single line of production code.
Adopted authority is a fact your source carries
A program compiled with USRPRF(*OWNER) runs with the owner's rights for as long as it executes. A clerk who cannot open the payroll file directly can still update it through that program. Most shops built this on purpose, because it is how you grant a task without granting a file.
The object report tells the auditor that a program adopts. It stops there. Two follow-up questions decide whether the finding closes or escalates.
The first question asks what the adopted authority reaches. If the owner profile carries all-object special authority, then every program that adopts it runs as a system administrator for the length of the call. Your team can read the owner profile in a minute. Matching that profile against the full list of programs that adopt it is the part nobody has done since the last audit.
The second question asks how far the authority travels. A program that adopts and then calls another program can pass those rights down the call stack, depending on how the called program was compiled. Following that path means reading call chains across source members. A cross-reference gives you a starting point. Programs that build a call target at runtime from a parameter do not appear in any cross-reference at all.
Which programs touch regulated data
The system tracks which files a program references, and DSPPGMREF reports it. That is a real starting inventory and your team should pull it before anything else.
It answers at the file level. An auditor is asking at the field level. A program that reads a customer master record with three hundred fields shows up on the report as a program that uses the customer master. Whether it reads the tax identifier or only the ship-to city is a question about the source.
Four common cases fall outside the cross-reference entirely.
- A program that builds an SQL statement at runtime from a parameter, where the table name appears nowhere in the source as a literal.
- A file opened through an override, where the program names one file and the job runs against another.
- A data queue that carries records between two jobs that never mention each other.
- A database trigger that fires a program no caller ever names.
Each of those runs in production tonight. None of them will appear in the document your team hands the auditor unless somebody reads the source and writes it down.
Where an AS400 security audit misses credentials in source
Every long-lived AS/400 shop has a few of these, and teams find them the same way every time. A standard AS400 security audit reports none of them, because none of them is a setting the system tracks.
CL programs that drive FTP transfers usually hold a user ID and a password as literal text. The script had to run unattended in 1998, and it has run every night since. Remote command calls carry the same pattern. Embedded SQL that reaches another database holds connection details. Test libraries hold copies of production records that were current on the day somebody took the copy.
Nothing on the system flags any of this, because none of it is a security setting. It is text inside a source member. A source-level pass is the only thing that finds it, and finding it is the entire finding.
Rotating a password does not clear the item either. The literal in the member has to change with it, and every member holding that literal has to change on the same night. Teams that miss one member find out when a transfer fails at two in the morning. A named list of the members prevents that call.
The evidence pack an auditor accepts
The strongest submission is a named list with a method attached. Four artifacts carry most of the weight.
- A list of every program that references each regulated file, with the fields each program reads or writes.
- A list of every program that adopts authority, with the owner profile and the special authorities that profile holds.
- A list of every source member holding credential text, with the member name and the library.
- A list of what the pass could not read, named by member, with the reason.
That fourth artifact does more work than teams expect. An auditor treats an unread member as an open item either way. A report that names it and explains why the copy member never resolved reads as control. A report that quietly omits it reads as an assertion, and assertions invite sampling.
Attach the date of the pass and the method. Our page on RPG code analysis covers how a team builds a source-level inventory.
Producing the pack without rewriting a program
Nobody reads four thousand source members by hand on an audit timeline. The practical method ingests the whole source library in one pass and builds the inventory from what the source says.
AS/Forward runs that pass. It reads six RPG dialects through a proprietary ingestion layer, then builds an interconnection graph across every program, file, copy member and display file in the library. From that structure it generates a plain-English description of each program. A developer can open the member and check any sentence in that description against the code it came from, which is the property an auditor cares about most.
The graph answers the impact question directly. Pick a field or an object in the migration view, and the view lists every program that moves with it. That is the same question the auditor asked about the account number, in a different suit.
The pass reports its own gaps. Unresolved copy members and missing dependencies land on the program page as warnings. A readiness status shows how confident the ingestion layer is in each program it read. Those warnings become the fourth artifact in the evidence pack, already named by member.
Where your source sits during that pass is the first thing a regulated shop asks. The preferred deployment runs air-gapped inside your own infrastructure, and nothing leaves your network. Model backends include Claude, OpenAI, Gemini and local models running on your own hardware, and an air-gapped install uses the local option. AS/Forward carries one US patent pending. Golden Path Digital tested the ingestion layer against roughly 5,000 programs drawn from PUB400 and public code repositories.
What changes at the next IBM i security audit
The reports about objects stay exactly as they are. Your team adds the source-level inventory beside them, and four things move.
Findings close faster, because the auditor gets a named list where last year they got a promise to investigate. Sampling drops, because a complete inventory removes the reason to sample. Remediation gets cheaper, because your team fixes the eleven programs on the list without touching the four thousand that were never in scope. Next year starts from an updated version of the same document, and the whole exercise costs your team a rerun.
The inventory also outlives the audit. It is the same map your team needs to scope a field change or brief a new developer. Our IBM i modernization assessment page walks through the full workflow, and the AS/Forward page covers the product itself.
Questions to bring to your next audit meeting
Ask your team these before the auditor does.
- Which programs on this system adopt authority, and what does the owner profile of each one carry?
- Which programs read the regulated field, at the field level, including the ones that build the file name at runtime?
- Which source members hold a user ID or a password as literal text?
- Which members did our last review fail to read, and why?
If your team cannot answer a question from a document, treat that as the first finding of the audit.
An IBM i security audit that answers all four from a document beats one that answers them from memory in the room. Talk to Golden Path Digital about a source-level pass before your next review. Call 501-232-7188 or use our contact page, and tell us which regulation is driving the date.