This article is based on reporting originally published on devops.com (2018). The underlying practices remain relevant to mainframe DevSecOps today.
The Speed-vs-Security Tension in Mainframe DevOps
DevOps teams face a persistent tug-of-war: ship software fast, or ship it securely. Move too quickly and a security vulnerability slips into production. Move too cautiously and the security review process becomes a bottleneck that kills organizational agility. This tension is well understood for cloud-native workloads, but it is equally—if not more—pressing for mainframe environments, where the stakes are especially high.
A large share of customer-facing applications depend on mainframe processing for core transaction handling. That means enormous volumes of personally identifiable information (PII), financial records, and other sensitive data flow through mainframe code and into mainframe data repositories every day. The mainframe platform itself is architecturally robust and highly resilient, but platform strength alone does not guarantee that the code running on it—or the processes surrounding it—are equally secure.
This is the problem that DevSecOps is designed to address: integrating security controls directly into the DevOps pipeline through automation, so that security is not an afterthought or a separate gate, but a continuous, embedded property of the development process. For mainframe teams, applying DevSecOps principles requires specific, platform-aware techniques.
Why Mainframe Security Deserves Its Own DevSecOps Strategy
The mainframe is often described as the most secure general-purpose computing platform available, and there is genuine engineering substance behind that claim. IBM’s pervasive encryption capability, for example, enables encryption of data at rest—including traditional VSAM files and databases—as well as data in transit, at very high transaction volumes with minimal throughput impact. Features like this make the underlying platform formidable.
However, platform-level security controls do not protect against insecure development practices, overprivileged user accounts, or unmasked sensitive data leaking through test environments. These are process and workflow problems, and they require DevSecOps solutions layered on top of the platform’s native capabilities.
Key Practices for Mainframe DevSecOps
1. Privatize and Mask Test Data
Application testing is faster and more realistic when it uses production data—real transaction volumes, real data distributions, real edge cases. Many mainframe teams rely on production data extracts for exactly this reason. The problem is that pulling live production data into a test environment without masking it exposes real customer PII to a broader set of users and systems than intended.
This creates two distinct risks:
- Security risk: Unmasked PII in a test environment is a data breach waiting to happen. Test environments typically have weaker access controls than production.
- Compliance risk: Regulations such as the EU’s General Data Protection Regulation (GDPR) restrict the purposes for which personal data can be processed. Using customer data for application testing may fall outside the scope of the original consent or lawful basis under which that data was collected.
The solution is data masking (sometimes called pseudonymization). Techniques such as randomly scrambling names, substituting fake account numbers, or tokenizing sensitive fields allow testers to work with data that has the same structural and statistical properties as production data, without exposing real customer identities. Crucially, this masking process must be repeatable and automated—building masked data sets on demand as part of the CI/CD pipeline, rather than as a manual one-off task that teams skip when under deadline pressure.
2. Enforce Credentialed User Auditing and Least-Privilege Access
Higher deployment frequency means more developers and testers accessing mainframe data and applications, more often. The larger the number of people touching sensitive systems, the greater the probability of accidental data exposure or inadvertent privilege misuse—even without any malicious intent.
User auditing—maintaining a detailed log of which credentialed users accessed which data, ran which jobs, and made which changes—provides the visibility needed to detect anomalous behavior and trace the source of any security incident. In regulated industries, this audit trail is also a compliance requirement in its own right.
Auditing is most effective when it is paired with disciplined user role management based on the principle of least privilege: users should have access only to the resources they need to perform their current role, and nothing more. In practice, this principle breaks down when employees change roles or responsibilities but their old access entitlements are never revoked. The result is privilege accumulation—users carrying forward permissions from previous roles that they no longer need and should not have. This is a genuine security vulnerability that auditing can detect but not prevent; only rigorous role lifecycle management can address it.
Recommended practices include:
- Automated provisioning and deprovisioning of access rights tied to HR role-change events.
- Regular access certification reviews where managers confirm that team members’ current permissions match their current responsibilities.
- Role-based access control (RBAC) frameworks that define standard permission sets for common mainframe job functions, reducing the risk of ad hoc privilege grants.
3. Build Security Gates into Automated Rollouts and Rollback
Automated deployment pipelines are a cornerstone of DevOps—and one of the most effective ways to speed up mainframe releases. Manual deployment processes create queues; when a small pool of mainframe specialists controls production pushes, workloads can wait far longer to be deployed than they spent in development and testing. Automation removes that bottleneck.
However, automating deployments without embedding security controls simply moves risk faster. The right approach is to treat the deployment pipeline itself as a security enforcement point:
- Mandatory approval gates: Require documented sign-off that security testing has been completed before code can progress to production. These approvals can be enforced programmatically in the pipeline, not just as a paper process.
- Audit logging of deployments: Every automated deployment should generate an immutable record of what was deployed, by whom it was approved, and when—creating a clear chain of custody for every production change.
- Automated rollback: If a security flaw or critical defect is discovered after a deployment, the ability to roll back instantly to the last known-good version is essential. A manual rollback process is too slow and too error-prone in an incident scenario. Automated rollback, triggered either by monitoring alerts or by an authorized operator, limits the blast radius of a bad deployment.
Bringing It Together: Mainframe as a First-Class DevSecOps Citizen
The mainframe has made significant strides toward full participation in modern DevOps workflows—integrated source control, automated testing frameworks, CI/CD pipeline tooling, and API exposure of mainframe services are all now achievable. The next step is ensuring that security is not treated as a separate workstream that mainframe teams must satisfy at the end of a sprint, but rather as an embedded property of every stage of the pipeline.
The three practices described here—automated test data masking, least-privilege access management with auditing, and security-gated automated deployments—form a practical foundation for a mainframe DevSecOps program. They address the real operational risks that arise specifically from the high-velocity, collaborative nature of DevOps when applied to systems carrying sensitive production data.
Organizations that integrate these controls will be better positioned to deliver on the mainframe’s traditional strengths—scalability, reliability, and throughput—while meeting the security and compliance demands of modern digital services. Speed and security are not mutually exclusive on the mainframe; they require deliberate process design to coexist.