Contents

Security checks on mainframe code

Agents also change JCL, REXX, CLIST and assembler, and some of those changes give code more authority than it had. gitta Enterprise makes sure that a person sees such a change before it reaches the main branch.

How the checks work

gitta looks at each changed file and compares it with the version the agent started from. When the new version does something security-relevant that the old one did not, the agent is told at its next step, gitta status shows it, and the merge output, .gitta/gitta.log and the audit trail report it, as for a weakened test. gitta does not decide that the change is wrong. It makes sure a person sees it.

What gitta reports

Code	What gitta reports
JCL	A job that starts running shell commands or TSO commands in batch, uses more privileged libraries, touches sensitive system datasets or runs with raised authority. Only what is new counts. A STEPLIB on a product load library is not flagged, and a proc that already runs shell or TSO steps is not flagged again for other edits. Symbolic parameters with a default in the same member are filled in first.
REXX and CLIST	New commands that run with authority, new network access, or passwords in the code.
COBOL	SQL built at run time from variables, and passwords in the code. Static SQL is not flagged.
COBOL, between agents	A security check that one agent weakens while another agent’s new code relies on it.
Assembler	Any change that touches authorisation or security interfaces. These always need a person.

Your own libraries and datasets

Out of the box, gitta flags only the system libraries that every z/OS has. It never guesses from a library’s name that it is authorised. Your own libraries, datasets and paths go into sections of the committed .gitta-security file. Each section adds to the built-in list, and * and ? work as wildcards. If an agent takes an entry off a list, gitta reports that change too.

Section	What you list
`[jcl-libraries]`	Your APF-authorised and other privileged load libraries
`[jcl-datasets]`	Sensitive datasets, for example security or system configuration
`[jcl-elevated]`	JOB and EXEC parameters that give a job more authority at your site
`[jcl-shell]`	Your own programs that run shell commands
`[rexx-paths]`	Paths of REXX and CLIST members without an extension
`[asm-paths]`	Paths of assembler members without an extension
`[asm-names]`	More macro and service names for the assembler rule
`[allow]`	A rule that a person has reviewed for some paths, with the reason. See Allow a reviewed line.

Lines before the first section name your own security checks, as for other languages. See Mark your own security checks.

LIMITS.* [jcl-libraries] # system and authorised load libraries PROD.SECURE.LOAD [jcl-datasets] # sensitive datasets PROD.RACF.* [jcl-elevated] # JOB and EXEC parameters with more authority CLASS=S [jcl-shell] # more programs that run shell commands MYSHELL [rexx-paths] # REXX members without an extension REXXLIB/* [asm-paths] # assembler members without an extension ASMLIB/* [asm-names] # more names for the assembler rule MYAUTHX

What an agent sees

Terminal

$ gitta status
  SECURITY: jcl/RPTJOB.jcl by jobstep: newly runs Unix shell commands from batch (`PGM=BPXBATCH`). Shell commands in a batch job run with the job's user and authority. Reported when merged; .gitta.toml decides whether it stops the merge.

Each finding is recorded in the audit trail. With weakened_checks set to block, the default in CI, the merge stops until the agent changes the code. See Removed tests and weakened checks.

Speed and what comes later

These rules read only the changed files, and they reuse the parse that the meaning check already made. They add no measurable time to the hook. Deeper checks need more than one file, for example whether input really reaches a dynamic SQL statement, or which RACF profiles a job gets. They are planned as an opt-in step at land and gitta pr-check that runs on the team server, not on the laptop.