devopsy.kinsta.cloud

Category: Sponsored Content

A Day with Developer Assist: Faster Fixes, Cleaner Commits
Security tools promise to help developers. In practice, many of them just relocate the burden. The vulnerability still needs to be understood, researched, and fixed, only now the developer is doing it across two or three tools instead of one, hours or days after they wrote the code in question.

The real test of an IDE security tool isn’t whether it finds issues. It’s whether a developer’s day actually gets better because of it. Fewer interruptions, fewer broken builds, fewer cycles spent fixing the fix.

Here’s what that looks like with Checkmarx Developer Assist across a typical working session.

Morning: An Unsafe API Call, Caught in Context

A developer is building out an authentication endpoint. Their AI assistant suggests a function to handle token validation, and at a glance, it looks reasonable. But Checkmarx Developer Assist flags the snippet for using an insecure token validation pattern, noting that the implementation fails to verify token expiration. The issue: the suggested implementation doesn’t properly validate token expiration, leaving a window for replay attacks.

Instead of just highlighting the problem, Checkmarx Developer Assist provides a contextual explanation of why the code is risky and offers a guided remediation directly in the editor. The fix is powered by the developer’s AI coding assistant (Copilot, Cursor, etc.), enriched with Checkmarx intelligence via MCP. The developer reads the reasoning, accepts the recommended change, and keeps working. Total disruption: about 30 seconds. No tab switching, no separate dashboard, no ticket filed for later triage.

This is the kind of vulnerability that traditionally wouldn’t surface until a post-commit scan—if it surfaced at all. By that point, the developer has already shifted to other tasks. The context is gone, the fix takes longer, and the review cycle adds days to the timeline.

Midday: A Dependency Flag with Real Context

Later, the developer adds a package to handle data serialization. Checkmarx Developer Assist immediately flags the dependency. The package itself isn’t compromised, but it pulls in a transitive dependency with a known CVE. Developer Assist identifies the vulnerable component and shows exactly where it is used across the project so the developer can understand the impact before making the upgrade.

This capability is known as Safe Refactor.

Instead of simply alerting the developer, Developer Assist turns remediation into a controlled workflow inside the IDE. It will:
1. Recommend a safer version or alternative package
2. Locate every place the dependency is used across the codebase
3. Update the code to use the secure version
4. Validate the changes to prevent breaking builds
Safe Refactor analyzes the dependency and usage graph before applying updates, ensuring consistent changes across the project and reducing the risk of incomplete fixes. This automated remediation workflow helps organizations upgrade vulnerable packages faster while maintaining application stability.

Why This Matters

Updating a vulnerable dependency across large codebases can take hours or days when done manually. Developers typically must:
- Investigate the vulnerability
- Identify a secure version
- Understand API changes
- Find every usage of the package
- Update and test the code
Safe Refactor compresses that effort into a reviewable workflow that executes in minutes, keeping developers productive while ensuring remediation is complete and reliable. Most tools stop here: a warning and a link to the CVE database. Checkmarx Developer Assist goes further, showing which files and code need updating for the upgrade to succeed. The developer swaps the package, confirms the blast radius is clean, and moves on.

Without that context, this decision gets deferred. The developer sees a yellow warning, doesn’t have time to research it, and figures it’ll get caught in the pipeline. Sometimes it does. Sometimes it comes back as a blocking finding, requiring a rollback.

Afternoon: A Clean Commit on the First Try

By late afternoon, the developer finished the feature. The code has been validated in real time as it was written. The unsafe API call was fixed in context. The risky dependency was swapped before it reached the repository. There are no surprises waiting in the CI/CD pipeline.

The commit passes on the first run. No rollback. No emergency patch. No late-afternoon Slack thread about a broken build.

This sounds like a small thing, but it compounds. Teams that routinely pass CI/CD on the first commit ship faster, spend less time on rework, and maintain a cleaner security posture without the stop-and-go friction that reactive scanning creates. MTTR drops not because the team got faster at triaging findings, but because most findings never make it past the editor.

What’s Actually Different Here

The pattern across the day is consistent: security feedback arrives at the moment the developer can act on it, with enough context to act confidently, and without forcing a context switch. That’s the difference between a tool that technically “shifts left” and one that genuinely fits into how developers work.

Three things make this possible. First, validation happens in real time as code is written, not in a separate scan phase. Second, remediation is guided and inline, so developers aren’t left to research fixes on their own. Third, Safe Refactor helps ensure dependency upgrades don’t break existing code, which is the hidden cost that makes developers reluctant to update vulnerable packages in the first place.

Three Ways to Test if Your IDE Security Tool Actually Saves Dev Time

If you’re evaluating tools or questioning whether your current setup is delivering on its promise, here’s a practical framework.
1. Count the context switches. Do developers have to leave the IDE to review findings, read PDF reports, or log in to a separate dashboard? Tools that surface fixes in-line with clear explanations keep developers in flow. Tools that require tab-switching and external research add friction that accumulates across every finding, every day.
2. Measure rework after “fixes.” Do suggested remediations cause broken builds, dependency errors, or failed tests? A fix that creates a new problem isn’t a fix. Safe Refactor cascades change cleanly across files and packages, so teams aren’t spending cycles repairing the repair.
3. Track MTTR in reality, not theory. Has the tool demonstrably reduced mean time to remediate? Are vulnerabilities resolved in minutes inside the IDE, or do they sit in a backlog until post-commit triage? The clearest indicator that a tool works is whether issues are resolved before code leaves the developer’s machine.
The Simplest Measure

The question worth asking isn’t “does this tool find vulnerabilities?” Most of them do, eventually. The better question is whether a developer’s day goes more smoothly with it than without it. If yes, adoption takes care of itself. If no, the tool becomes shelfware regardless of how many features it lists.

Learn more about the ROI of Agentic AppSec: Read the article.

See how Checkmarx Developer Assist fits into a real development workflow: Watch the demo.
April 29, 2026
Agentic AI for Defense: How Checkmarx Turns Security into a Coding Partner

“AI-powered” has become the default label for every security tool on the market. But there’s a meaningful difference between a tool that uses AI to generate alerts after the fact and one that actively participates in development, preventing vulnerabilities as code is written.

That difference is what separates reactive AI from agentic AI. And it matters more now than ever.

What “Agentic” Actually Means in AppSec

In the context of application security, agentic AI isn’t a buzzword. It describes a specific set of capabilities: the tool proactively surfaces security issues in real time, understands the context in which code is being written, and recommends fixes before insecure patterns reach the pipeline. The developer still makes the call. But instead of finding out about a vulnerability hours or days after committing it, they get guidance at the moment they can act on it most efficiently.

Three qualities define the approach. Agentic AI is proactive, performing inline validation as developers write rather than waiting for a post-commit scan. It’s context-aware, understanding the intent behind a code pattern rather than just matching syntax rules. And it’s assistive, offering guided remediation and recommended fixes that developers can review, accept, or modify, keeping decision-making authority where it belongs.

Most tools on the market today check one of those boxes, maybe two. Checking all three is what makes the approach genuinely agentic.

What This Looks Like in Practice

An agentic approach only works if it reaches every layer of the development lifecycle: the individual developer writing code, the organization setting policy, and the leadership team measuring outcomes. Gaps between those layers are where risk accumulates.

Checkmarx built its Checkmarx One Assist platform around that principle, with each layer addressing a distinct challenge.

Developers need remediation guidance without leaving their editor. Developer Assist validates code in real time inside VS Code, JetBrains, Cursor, and Windsurf, including AI-generated completions. When it identifies a vulnerability, it provides guided remediation in-flow rather than routing developers to a separate dashboard. For changes with broader impact, Safe Refactor cascades fixes across affected files and dependencies, ensuring a local fix doesn’t introduce new breakage elsewhere.

Organizations need governance that keeps pace with how code is actually written. Policy Assist lets teams codify security guardrails scoped by repository, language, or role, and those rules are enforced consistently whether a developer is writing code manually or accepting suggestions from an AI assistant. Policies become active participants in the coding process rather than gates that trigger only during a CI/CD run.

Security leaders need to measure what’s working. Insights Assist tracks MTTR, SLA adherence, and risk trends across the portfolio. Instead of vague assurances about security posture, CISOs and their teams can see how quickly vulnerabilities are resolved, where bottlenecks persist, and whether improvements are real or cosmetic.

What makes this agentic rather than just comprehensive is that these layers operate together. The IDE validation, the policy enforcement, and the executive visibility reinforce each other continuously, not as separate products stitched together after the fact. Most AppSec vendors cover one of these layers well. Some cover two. Checkmarx is the only agentic platform that works across all three: IDE, CI/CD, and portfolio, in a single integrated experience.

Eight Questions to Test Whether a Vendor’s AI Is Truly Agentic

Not every tool that claims agentic capabilities delivers them. Here’s a practical framework for separating substance from marketing.

1. Does it act before commit, or only scan after the fact? Agentic AI validates intent and logic in the IDE as code is written. Reactive tools run post-commit scans and hand developers noisy reports long after they’ve moved on.

2. Can it explain its reasoning? Agentic AI provides context-aware, human-readable explanations for why a line is risky. Reactive models flag issues without justification, which erodes developer trust over time.

3. Does it fix, or only find? Agentic platforms generate safe refactors, package blast-radius insights, and guided remediation. Reactive tools stop at highlighting the problem and leave the fix to someone else.

4. Can it enforce policies in real time? Agentic AI applies organization-wide security rules inline, scoped by repo, language, or role. Reactive tools push enforcement downstream into CI/CD, where catching a violation means rolling back work that’s already done.

5. Does it adapt to generative AI-specific threats? Agentic AI detects threats like Lies-in-the-Loop (LITL), prompt injection, shadow AI usage, and poisoned packages. Reactive tools weren’t built for these vectors and miss context-driven exploits.

6. How does it handle shadow AI? Agentic platforms surface unapproved AI usage across teams, scanning completions from tools like Copilot, Claude, or Replit AI. Reactive vendors ignore shadow AI entirely, letting policy drift accumulate unchecked.

7. What’s the measurable impact on MTTR and throughput? Agentic AI reduces mean time to remediate and accelerates release cycles by eliminating rework. Reactive tools often add friction to the process, reintroducing the “slow security” problem they were supposed to solve.

8. Is it embedded everywhere developers work? Agentic AI integrates across IDEs, repositories, CI/CD pipelines, package managers, and SIEM/SOAR platforms. Reactive AI is typically bolted onto a single layer (often just the repo), creating gaps everywhere else.

Put Your Current Vendor to the Test

Run these eight questions against whatever AppSec tools you’re evaluating or already using. The answers will quickly tell you whether you’re looking at a genuinely agentic platform or a reactive tool repackaged under a new label. The distinction will only matter more as AI-generated code becomes the norm rather than the exception.

Download the Agentic AppSec Buyer’s Guide: Download Now →

See what agentic AI looks like in practice. Watch the Checkmarx Assist demo →

April 23, 2026
Iceberg Won the Format War — Now Comes the Hard Part

Apache Iceberg has effectively won the open table format conversation. AWS, Google Cloud, Microsoft, Snowflake, Databricks — every major platform has thrown its weight behind it. If you work in data engineering or platform operations, the question is no longer whether Iceberg is the right foundation. It’s what it actually takes to run it day to day.

That second question doesn’t get nearly enough airtime. And it’s the one that determines whether your Iceberg adoption goes well or becomes a slow-motion infrastructure project that nobody budgeted for.

The Gap Nobody Talks About

Here’s what Iceberg gives you: a table format with schema evolution, time travel, partition evolution, and engine independence. Here’s what Iceberg does not give you: a way to get data into those tables, a way to model and transform it once it’s there, a way to coordinate when things run, or a way to keep table health in check as data piles up.

Put differently, Iceberg defines how tables behave, not how to operate the pipelines around them.

Most teams discover this the hard way. They pick Iceberg for its openness and flexibility, then spend months wiring together ingestion tools, dbt jobs, schedulers, and homegrown maintenance scripts. The individual pieces work. The thing they form is fragile because reliability lives in the gaps between tools rather than in any single place you can point to and say, “This is responsible.”

Why This Is a DevOps Problem

If you’ve been in DevOps for any length of time, this should ring a bell. It’s the same mess software delivery was in before CI/CD grew up: too many disconnected steps, no single system of record, and failures that only show up at the seams between tools. Data pipelines have just been slower to hit this wall.

Here’s a scenario I’ve watched play out multiple times. A schema change is applied to a production database. The ingestion tool picks it up and starts writing new fields into Iceberg. A dbt Core job runs later on its hourly schedule. It either blows up because its assumptions about the schema are now wrong, or — worse — it succeeds while quietly producing partial results that nobody catches until a dashboard goes sideways downstream. Meanwhile, table maintenance (compaction, snapshot expiry, orphan file cleanup) is running on its own cadence, completely unaware of what ingestion or transformation just did.

When you debug this, you’re context-switching across four systems, none of which are broken on their own. The problem is coordination. And the coordination layer? That’s you, at 3 a.m., reading runbooks in a Slack thread.

DevOps figured out years ago that humans make terrible glue between systems. That’s what drove the shift from manual deployments to automated pipelines with feedback loops, observability, and rollback. Data engineering is at an inflection point, and Iceberg adoption is accelerating it.

Schedules Are Holding Your Iceberg Stack Together with Duct Tape

The deeper architectural issue is how most Iceberg stacks coordinate work. Almost everyone uses time-based schedules: ingest every five minutes, run dbt hourly, and compact nightly. Fine when everything is batch and nothing changes. Not fine when ingestion is continuous, schema changes are routine, and table operations have a real impact on query performance.

Iceberg’s own snapshot mechanism gives us a better primitive. Snapshots capture the exact state of a table at a point in time. A system built around table state can answer questions that schedules can’t: this snapshot invalidated these downstream models; these tables now need compaction; downstream consumers can read a consistent version once these steps finish.

If you’ve worked with event-driven architectures in application development, this should feel natural — the state change itself triggers the next action instead of a cron job polling for it. For data platforms, this means the scheduler becomes an implementation detail rather than the load-bearing wall. It also means lineage gets real: not just “this source feeds this table” but “this version of the source produced this version of the model,” traceable to the snapshot.

You Traded Vendor Lock-In For Internal Platform Lock-In

There’s an irony that keeps coming up in my conversations with data platform teams. They chose Iceberg to avoid vendor lock-in. Then they spent six months building a bespoke pipeline platform — custom orchestration, monitoring scripts for table health, runbooks that span four tools, tribal knowledge about which manual steps to run when things break — and now they’re locked into that instead. Different lock-in, same result: you can’t easily change course because too much depends on the specific way you wired it all together.

This compounds fast. A handful of Iceberg tables can be managed with scripts and good intentions. A hundred tables with interdependencies need a system. Most teams hit this realization somewhere around table thirty, when operating pipelines starts eating more time than building them.

Anyone who’s been around long enough remembers when companies managed deployments with shell scripts and SSH. It worked until it didn’t. The shift to declarative infrastructure and managed delivery pipelines didn’t happen because the scripts stopped functioning. It happened because the cost of scaling that approach grew faster than the team. We’re at the same crossroads with data pipelines on Iceberg.

What to Look for in an Iceberg Pipeline Layer

If you’re evaluating your Iceberg strategy or about to start one, here’s how I’d think about the pipeline layer you’ll need.

Ingestion and transformation should live in the same system. When they’re separate, schema evolution and data quality become coordination headaches instead of pipeline features. Data quality tests shouldn’t be downstream assertions that catch problems after you’ve already burned the compute. They should be contracts at the boundary where data enters.

Table operations—compaction, snapshot expiry, metadata cleanup—need to be treated as first-class concerns, not cron jobs you set up once and forget about. They directly affect query performance and storage costs, and they need awareness of what the pipeline is doing. Running compaction during a large ingestion batch is a great way to create problems that are hard to diagnose.

The system should run inside your VPC. If you picked Iceberg for data sovereignty and security, sending your data through someone else’s infrastructure undermines the whole point. This isn’t hypothetical — in financial services and healthcare, regulations and company policies often mandate that data never leaves the VPC.

And the pipeline layer should let you build once and serve many consumers from the same Iceberg tables: analytics, data science, AI workloads, and data sharing. Iceberg makes this architecturally possible. The pipeline layer is what makes it operationally real.

Where These Conversations Are Happening

What I like about the Iceberg ecosystem is that these operational problems are being discussed in the open. The format is open source, governance is through the Apache Software Foundation, and the community skews heavily toward practitioners who are running this stuff for real.

If any of this resonates, Iceberg Summit 2026 is worth your time. It’s April 8-9 in San Francisco (Marriott Marquis), run under the Apache Software Foundation, and it’s the one event where you’ll find core maintainers, production users, and platform architects all in the same room. Last year’s edition had serious depth — not vendor keynotes, but real case studies and technical deep dives. I expect this year to go even deeper on the operational side, which is where the hard problems are right now.

The Hard Part Starts Now

Iceberg has crossed the adoption threshold. The format debate is over. What hasn’t been settled is how teams will actually run it without drowning in operational overhead.

If you’ve spent time in DevOps, you know the tools are only as good as the system they form. A great CI server doesn’t help much if your deployment process is held together with hope and shell scripts. The same is true for data pipelines on Iceberg. The question for 2026 isn’t whether to build on Iceberg. It’s whether your pipeline architecture can keep up.

March 30, 2026
When AI Gets It Wrong: The Insecure Defaults Lurking in Your Code
The arrival of generative AI in the software development lifecycle (SDLC) is arguably the biggest shift in coding in decades. For development teams, tools like GitHub, Copilot, and other AI assistants act as a massive force multiplier, automating boilerplate, suggesting complex logic, and significantly accelerating time-to-commit.

But as organizations rush to equip their teams, a quiet crisis is forming in the codebase. While AI helps developers write code faster, it also helps them write insecure code faster.

The problem isn’t that the AI is malicious. It is that today’s models do not understand security context or intent. Generative AI models are trained in vast repositories of public code, billions of lines written over decades. This training data, while containing brilliance, also includes millions of deprecated patterns, insecure configurations, and “quick-fix” tutorials that were never meant for production. Because generative AI is probabilistic, it doesn’t understand security. It only understands patterns. If the training data relies heavily on insecure database connections, the AI will simply default to suggesting those flawed patterns to developersx.

The Most Common AI-Generated Vulnerabilities

At Checkmarx, we observe distinct, persistent categories of flaws that AI assistants are prone to generating. These are fundamental security errors that can easily bypass standard peer reviews because they “look” syntactically correct.

1. SQL Injection. It’s Back!

SQL Injection (SQLi) should be a relic, yet Checkmarx researchers consistently observe it as one of the most frequent flaws surfacing in AI-generated code. Why? Because the internet is full of older tutorials that use simple string concatenation to build queries. When a developer asks an AI to “write a query to find a user by ID,” the model may default to older, insecure examples due to prevalence, ignoring modern parameterization. The result is a functional query that opens the door to database manipulation the moment it hits production.

2. Weak Cryptography and Authentication

When asked to handle authentication or hashing, AI models often retrieve “classic” examples from their training data. This leads to suggestions using algorithms like MD5 or SHA-1, standards that have been broken for years, rather than modern, secure alternatives. The code compiles, the tests pass, and teams unknowingly bake a critical flaw into the application’s identity layer.

3. Secrets in Plain Sight

AI models trained on public repositories have “seen” thousands of API keys, tokens, and credentials accidentally committed by other developers. We frequently see AI assistants suggesting code blocks that include placeholder credentials. They sometimes suggest hardcoding keys for “testing simplicity,” a dangerous habit that often bleeds into production.

4. The Supply Chain Trap

AI assistants are eager to help developers import packages to solve problems, but they rarely vet the health of those packages. An AI might suggest a library that is popular but unmaintained, or one that was recently compromised. This introduces a supply chain risk: a single “quick import” can bring in a web of exploitable transitive dependencies.

Four AI-Generated Code Smells Every Developer Should Catch Early

As engineering teams lean more heavily on AI, developers need to develop a new “muscle memory” for reviewing suggestions. Security cannot just be a tool; it has to be a critical step in the coding process. Here are four specific “AI code smells” examples that should trigger immediate skepticism.

1. Hardcoded Secrets and Credentials
- The Smell: The AI suggests variable names like apiKey or admin:admin defaults.
- The Risk: The AI is mimicking bad practices from training data. This causes an instant breach if the code is promoted to production.
2. Hallucinated Logic and Unsafe Defaults
- The Smell: The AI invents functions that “look right” but do not map to real APIs. It suggests permissive configurations or disabled TLS verification.
- The Risk: The AI prioritizes functionality over security rules. This introduces overbroad regex sanitization or opens security holes that are difficult to spot.
3. Vulnerable or Outdated Package Recommendations
- The Smell: The AI suggests a quick install for a package without providing context on its version history or CVE record.
- The Risk: Developers import a library with known vulnerabilities. This compromises the supply chain with exploitable transitive dependencies.
4. High Blast-Radius Refactors
- The Smell: A developer asks the AI to refactor a single function. The suggestion ripples across multiple files and modules.
- The Risk: The AI lacks application-wide context. These subtle changes break security checks, invalidate unit tests, or downgrade dependency safety. Without Safe Refactor capabilities, the resulting rework can be massive.
Moving from “Scan Later” to “Fix Now”

The only way to capture the velocity AI promises without inheriting the hidden technical debt it leaves behind is to bring security context directly into the AI workflow.

Security as a Real-Time Partner

This is a core philosophy behind Checkmarx Developer Assist. Instead of waiting for a nightly scan, Developer Assist runs inside the IDE, validating AI completions in real time.

Because flagging the problem is only half the battle, development teams need solutions, not just alerts, to truly maintain velocity. This is where Safe Refactor comes in. If an AI suggests a block of code with SQL injection vulnerability, Developer Assist catches it before the developer hits “save” and generates a secure, parameterized version of that code, offering to swap it instantly. Developer Assist also maps the Package Blast Radius before a developer accepts a recommendation, analyzing dependencies and vulnerabilities to show the potential impact that a simple import could have on the entire application’s security posture.

AI acts as a powerful engine for speed, but it lacks judgment for security. It requires a partner to distinguish “working code” from “secure code.”

Ready to see safe coding in action? Watch the Checkmarx Developer Assist demo to see how we catch and fix AI-generated vulnerabilities in the IDE.
March 4, 2026
The AI Productivity Paradox: How Developer Throughput Can Stall

Software engineering leaders have invested heavily in generative AI coding assistants for over two years—and for good reason. For many teams, the productivity gains appear significant. I hear the same story in conversations with leadership at dozens of enterprises: thanks to AI, developers complete tasks faster, write more code, and spend less time on boilerplate activities.

But I am also seeing a potentially dangerous paradox emerging; perhaps a new kind of technical debt, and a danger that you will experience at an accelerated pace (acceleration being the true hallmark of everything AI). While individual productivity is soaring, overall throughput, meaning the rate at which secure, stable, production-ready code is deployed, is stagnating or even declining in many cases.

The reason is a simple but costly equation: a significant percentage of AI-generated code contains vulnerabilities. AI-assisted code always looks correct on the surface (a hallmark of generative AI, which is trained first and foremost to appear correct, whether or not it is correct). But hard-to-detect vulnerabilities in AI-assisted code create bottlenecks in the CI/CD pipeline where the time saved in writing the code is lost or even outweighed by the ensuing security-driven regressions, failed builds, and remediation cycles.

This is a high-friction environment for application development where security teams, already stretched thin, can drown in a firehose of new alerts triggered by AI-generated vulnerabilities. Developers, in turn, grow frustrated as their velocity is throttled by a security model that feels punitive, rather than collaborative.

A “Shadow AI” Problem

In some organizations, the initial reaction has been to restrict or tightly control AI tool usage. The benefits are too compelling for developers to ignore, and they will simply use AI on their own, regardless of whatever policy their organization sets.

This is the worst of all possible worlds. Not only is insecure code still being introduced, but leadership now has zero visibility or control over which tools are being used. This complete loss of governance is a compliance and security risk that far outweighs any perceived benefit of a ban.

A Solution: Security Enters the IDE

For years, the industry mantra has been “shift left,” the move of security testing from production into the CI/CD pipeline. But the AI boom might make that model insufficient (at an accelerated pace, of course), because a post-commit scan is already too late if the code is unnoticeably compromised from the start. The productivity gain was already lost at the point of creation.

A better code security paradigm might be “shift all the way left”: move security validation from the repository into the developer’s integrated development environment (IDE) itself. Let’s get security collaborating with the AI assistant and the developer in real time.

This is more than just a workflow tweak; it’s a fundamental change in cognitive load. A post-commit scan that finds a flaw forces a developer to stop, context-switch back to a task they thought was “done,” and try to fix a problem they no longer have top of mind. An in-IDE validation agent, by contrast, provides an immediate, in-context suggestion, often before the vulnerability is even in production. It also turns security from the classic Department of No into a pretty seamless development partner. In this model, validation doesn’t happen after the work is done; it happens as the code is being generated.

Intercept insecure code at its point of origin, and you should transform raw developer productivity into secure and effective business throughput.

Five Questions Engineering Leaders Can Ask

As you navigate the use of AI coding tools, consider your approach within an in-IDE paradigm. Ask yourself and your teams:

1. How will we validate AI-generated code before it’s committed?

If your only guardrail is a post-commit scan, you’re risking starting behind. Real-time, pre-commit validation is more than just a feature; it’s a newly achievable requirement for securing an AI-powered software development lifecycle. Catch flaws at the point of creation and reject the risk of the higher costs of finding and fixing them later.

2. Can we see and control which generative AI tools our developers are using?

Obviously, a policy that only covers your officially sanctioned AI assistant is blind to the reality of shadow AI. Visibility across all tools, official or not, is important because you can’t secure what you can’t see. This visibility is the prerequisite for any meaningful governance, allowing you to set guardrails that apply equally to all tools.

3. Do our security policies extend into the AI assistant itself?

Traditional static policy checks are easily bypassed by AI tools. From data handling to open-source licenses, make sure you know how your policies will be enforced at the moment of code generation, not just at scan time. You want your policies to actively guide the AI in generating code that is compliant from the start.

4. What’s our plan for unsafe package recommendations and refactors that have a wide blast radius?

AI assistants are notoriously proficient at suggesting outdated or vulnerable packages. A seemingly small, helpful suggestion can have a massive ultimate effect with the potential to break security at scale. This is one of the most insidious AI risks, given the AI model training point of outputs that look correct and trustworthy. To prevent any one AI-fueled commit from breaking an entire application, you should know the potential size of the blast radius and enable safe refactoring.

5. How will we measure developer adoption and ROI?

The inevitable, classic question in IT applies here as well. Security that slows developers down is highly likely to be bypassed or ignored. Developer adoption rates, reduction in mean time to resolution, SLA adherence, and, most importantly, developer throughput—not code commits but code in production—are good success metrics. In “shift all the way left,” the security tools that work are the ones developers are using, and they will only use them if they add value to their work without adding friction.

The era of reactive code security is probably beginning to end. At the very least, the challenge is no longer if we use AI but how we will govern its use. The most successful organizations will retreat from the game of policing their developers and into the business of empowering them with the tools to code securely and rapidly from the very first line.

February 25, 2026
The Cloud Scout Model Delivers Reliability As An Embedded Capability

Organizations today face a structural problem that is slowing down their move to cloud-native maturity. They’ve adopted modern DevOps tools, yes. They’re running Kubernetes. They’re using sophisticated observability platforms. But the people-and-process piece often remains stuck in the traditional enterprise IT paradigm.

The rift is simple: developers are tasked with delivering features, and operational staff are tasked with fixing what breaks. This creates a painful gulf between product intention and operational reality. Reliability ends up being a reactive, fragmented service. You build a new feature, you deploy it, and then you wait for SRE to tell you it’s broken. It isn’t fast, and it certainly isn’t efficient.

This model keeps senior, expensive engineers trapped in a vicious cycle. They’re stuck fighting the same fires over and over again. They become symptom fixers rather than designers of prevention. The infrastructure never quite becomes self-healing because no one is positioned to own that outcome end to end, from the first line of code to the production platform. It’s too distributed, too siloed.

Moving past this reactive trap requires more than just better alerts. It demands a strategic reorganization of talent. You need to embed architectural expertise directly into the product teams that own the code. You need to deploy what SOUTHWORKS calls the Cloud Scout model. You can watch the full SOUTHWORKS presentation from Tech Field Day at KubeCon North America 2025 on the website.

A Cloud Scout isn’t just another SRE. They’re a highly senior engineer, someone with deep platform knowledge and cloud-native expertise, who is embedded directly into the product team. Their role is not to replace the existing SRE function, which remains vital for platform maintenance and shared services. Their role is to serve as a catalyst and co-designer during their fixed-term on-site placement.

The key benefit here is proximity. The Cloud Scout sits with the development team. They attend the stand-ups. They are involved in the design sessions for new features. They understand the business domain and the why behind the latest push. This deep context is what allows them to influence design for reliability from the first architectural sketch onward. They’re helping the team co-design systems that are resilient, observable, and self-healing from the start.

This structural alignment is the only way to genuinely shift reliability from a cost center (a team that cleans up messes) into an accelerator of product innovation. If you can eliminate an entire class of potential failures during design review, you haven’t just saved a few tickets. You’ve liberated the team as a whole to move faster and focus on value-added features.

The Cloud Scout’s duties extend beyond the whiteboard. They are the human bridge between the application code and the underlying cloud fabric. They leverage the tooling, yes, but they use it to gain architectural insight, not just to triage alerts. This is where advanced tooling, specifically agentic AI and machine learning, comes into play.

Modern platforms generate truly staggering amounts of telemetry data. No human can process all that noise efficiently. The embedded engineer uses AI-powered companions to process that data. These systems analyze billions of metrics, logs, and traces, identifying non-obvious patterns, subtle architectural smells, and potential points of failure that a human eye would miss entirely. They can propose solutions or codify remediations.

But an organization can’t simply trust an autonomous system to make architectural decisions, can they? Of course not. The embedded engineer provides the crucial human-in-the-loop validation. They review the AI’s data-driven insights and confirm that they align with the business goals, budget constraints, and the long-term architectural roadmap. This combination of deep human expertise and massive machine processing is what transforms reactive maintenance into data-driven, preemptive design change.

This co-design function benefits the code. It raises the maturity of the entire team. The Cloud Scout constantly facilitates knowledge transfer, showing developers how to build resilient systems. This means that when the engagement ends, the product team is left significantly more capable and self-sufficient. They haven’t just had a problem solved for them; they’ve learned to build better systems themselves.

The outcomes are clear and measurable. Organizations implementing this model see a significant reduction in alert fatigue because the underlying systemic flaws are being fixed at the source. They achieve faster time-to-resolution when outages occur because the person responding knows both the product and the platform intimately. And most importantly, they accelerate the feature roadmap because their reliability work is now integrated and proactive, not siloed and reactive.

Every company facing the complexity of cloud-native development and the pressure to adopt AI has to de-risk its innovation. You can’t afford to have your senior talent stuck in a maintenance cycle. Embedding that senior expertise and strategically placing Cloud Scouts to co-design and accelerate aren’t just smart moves. It’s a necessary evolution for achieving actual velocity in the modern technical landscape. It stops being about fixing the plane after it’s taken off and starts being about building a better plane entirely.

Watch the full SOUTHWORKS presentation or catch up with all the events on the Tech Field Day website.

November 26, 2025
The Future of DevSecOps: From Shifting Left to Shifting Smart
For the better part of a decade, a revolutionary idea has reshaped enterprise security: the “shift left” movement. This mantra taught us to view the software development lifecycle (SDLC) not as a finish line for security, but as its starting point. By embedding security checks at the earliest possible stage, we made incredible strides in building safer software from the ground up. The promise was compelling: catch vulnerabilities early, reduce remediation costs, and build security into the DNA of every application.

But as organizations modernized their SDLCs and release cycles accelerated from months to hours, something unexpected happened. The revolution began revealing its limitations.

Developers were never security subject matter experts. They never asked to be. Yet today, they’re responsible for early-stage security testing, vulnerability remediation, policy compliance, and their core coding work, all simultaneously. It’s like spinning plates while riding a unicycle on a tightrope. When developers are stretched this thin, something has to give. Morale suffers. Quality degrades. The very people we meant to empower end up overwhelmed.

Under intense pressure to deliver fast and meet aggressive deadlines, security protocols become the easiest thing to defer. Testing gets abbreviated. Thorough reviews get skipped. When deadlines loom and alerts keep flooding in, even well-intentioned teams will bypass measures they know they shouldn’t.

Then there’s AI-generated code: the seemingly perfect solution to developer overload. Tools like GitHub Copilot have become cognitive relief valves, offering instant code snippets and rapid prototyping. They’re genuine time-savers. But developers, already pressed for time, are pushing AI-generated code to production without thorough vetting. The code works, so it ships. But untested AI code can harbor hard-to-trace vulnerabilities, hidden dependencies, and security flaws that won’t surface until they’re exploited. The tool meant to ease the burden is quietly accumulating technical debt.

The intent of shift left was sound. The outcome has been uneven. Tool sprawl proliferated. Feedback loops disconnected. This isn’t a developer problem; it’s a structural one. And it raises a critical question: Did shift left create more developer toil rather than reduce it?

The Limits of a Linear Approach

These developer-level pressures are symptoms of deeper architectural flaws in how we’ve implemented shift left. Modern software delivery moves too quickly for a linear security model. Security must be continuous, intelligent, and embedded throughout.
1. It Ignores the “Right”. A perfectly scanned application in the CI pipeline can still be compromised in production due to misconfigurations, novel attack vectors, or zero-day exploits. An obsessive focus on the “left” creates a false sense of security, leaving organizations blind to runtime threats. True security must protect software throughout its entire lifecycle, not just during development. Without “shielding right,” you’re only fighting half the battle.
2. It Lacks a Feedback Loop. The most valuable security insights come from production: real attacks, actual exploits, observed behaviors. Yet in a purely left-focused model, this critical intelligence stays siloed. There’s no automated mechanism to feed production learnings back into development pipelines or update scanning rules. Teams repeat the same architectural mistakes, leaving the door open for similar breaches in the future. Security should get smarter with every incident, but shift left doesn’t learn from the right.
3. It Operates Without Context. A vulnerability scanner flagging a library in your CI pipeline operates in a vacuum. It has no idea whether that code is reachable in production, what its business criticality is, or whether it’s behind a disabled feature flag. Developers spend hours investigating alerts only to discover they’re chasing theoretical risks while missing critical ones. Without context, security tools generate noise, not intelligence.
The New DevSecOps Playbook: “Shift Smart” with Intelligence and Context

The future of DevSecOps lies in a different model: shift smart. This approach isn’t about when security happens, but how. It’s about applying precise security intelligence and automation at the right place, at the right time, with the right context, in a way that reduces developer burden rather than adding to it.

What does this require? Three fundamental capabilities:
1. Unified Context Across the Lifecycle. You can’t protect what you can’t see. Organizations need a cohesive data fabric that connects every stage of the SDLC, from code commit to production runtime. This means integrating existing tools (GitHub Actions, Jenkins, security scanners, artifact repositories) into a single source of truth. When you can see the full picture, security signals stop operating in isolation.
2. Intelligent Automation That Scales. With this shared context, organizations can shift from reactive firefighting to proactive orchestration. Intelligent automation can answer questions like, “This vulnerable library was just detected. What other microservices use it, what is their blast radius, and which teams need to act?” Contrast this with the manual alternative: a security alert arrives, followed by cross-team meetings, manual repository searches, and ticket assignments to track remediation. This removes the investigative burden from developers, transforming security from a bottleneck into an accelerator.
3. Bi-Directional Feedback That Learns. Security must flow both ways. Insights from production monitoring should automatically update policies in development pipelines. A newly discovered attack vector in the wild should trigger preventative checks earlier in the cycle. This bi-directional flow creates a self-healing system that gets smarter with every deployment, every incident, every lesson learned.
At CloudBees, this thinking shaped our approach with Unify: an operating layer that connects your SDLC tools, unifies their data, and enables intelligent orchestration that understands the full context of your software delivery.

The Mandate for Modern Security

So, is shift left dead? Not necessarily, but it needs a serious rethink. What we’re hearing from forward-thinking organizations is a change in approach: they’re moving beyond linear security models and building intelligent, adaptive ecosystems that are automated by default and secure by design.

This is the essence of shifting smart. Not more responsibility for developers. Not more tools. Instead, a system where security becomes ambient: always on, always aware, and always improving. Security is so well integrated that developers barely need to think about it. It’s the difference between building more gates and paving a golden path.

Stop Just Shifting Left; It’s Time to Shift Smart

CloudBees Unify transforms scattered security tools into one enterprise-grade cohesive, policy-driven control plane. Keep your tools, gain compliance, developer alignment, and faster remediation. Learn more at cloudbees.com/unify.
November 20, 2025
Beyond the Platform: How Enterprises Can Unify Their DevOps Toolchains for Better Governance and AI Readiness
For over a decade, the core mission of enterprise IT has been to accelerate innovation. This drive has led to a fundamental shift in how software is built, favoring team autonomy and the freedom to choose the best tools for the job. Whether it’s a specific CI/CD pipeline, a new testing framework, or a specialized security scanner, empowering teams with the right technology has undeniably fueled velocity.

But for many organizations, this freedom has also created a quiet, creeping complexity. What starts as a few autonomous teams making smart choices can, at scale, become a sprawling ecosystem of hundreds of loosely connected and disconnected tools. Platform engineers spend their days patching security holes in custom scripts, while developers lose hours to context-switching. The very freedom that drives innovation can also introduce fragmentation, operational overhead, and hidden security risks.

The False Choice We’ve All Been Sold

For too long, the industry has presented a false choice to solve this problem. On one side, you have the chaotic reality of managing Frankenstacks, held together by custom scripts and siloed knowledge. On the other side, you’re offered the promise of the all-in-one DevOps platform. The pitch is seductive: a single, simplified solution to rule them all. But this path comes with a heavy price. It demands painful migrations, forces developers to abandon the tools they love, and locks you into someone else’s roadmap.

At CloudBees, we believe this is a fundamentally broken choice. Your diverse technology stack isn’t a problem to be addressed but an advantage to be fully unlocked.

A New Playbook

The real risk in the enterprise isn’t the diversity of tools; it’s the lack of a cohesive fabric connecting them. The danger lies in the blind spots of “shadow security” and compliance gaps that emerge when no one has a single view of the entire software delivery lifecycle (SDLC).

This is the principle behind CloudBees Unify. It’s not another platform to add to the pile. It’s an operating layer that works with the tools you already have, from Jenkins and GitHub Actions to a host of other CI/CD solutions. It provides centralized governance, security, and visibility without forcing a revolution.
1. Unified Governance without Friction: CloudBees Unify allows you to set and enforce policies across your entire toolchain from one central place. Imagine a new SOC 2 compliance standard needs to be rolled out. Instead of a yearlong project, you define the policy once in Unify and it’s instantly enforced everywhere, for every team.
2. Continuous Security That’s Baked In: Shifting left shouldn’t be a burden on developers. Unify integrates automated security scans and vulnerability reporting directly into the developer workflow.
3. Unmatched Visibility Across the SDLC: Unify provides a single, consolidated view of your entire delivery ecosystem. It provides real-time analytics on flow metrics and end-to-end artifact traceability, enabling you to quickly identify bottlenecks and prove compliance.
As Sudhakar Parakala, VP of IT and Applications at Synaptics, noted, “CloudBees Unify understands what many platforms miss—ripping and replacing simply doesn’t work at the enterprise level. We need solutions that complement our existing systems, not conflict with them.”

This is the core of our philosophy that modernization shouldn’t feel like a migration; it should be an evolution that allows you to innovate most effectively, at your own pace.

A New Perspective: Unification as the Foundation for What’s Next

Managing today’s complexity is one thing, but preparing for the future is another. The next wave of software delivery won’t just be automated; it will be intelligent. Generative AI and agent-based systems are beginning to transform how we build, test, and deploy software. But for AI to be effective, it needs one thing above all else: context.

An AI agent can’t suggest an intelligent fix, optimize a pipeline, or identify a security risk without understanding the full picture. A fragmented, siloed toolchain is a context-poor environment that leaves AI flying blind. By creating a connected, context-aware ecosystem, Unify becomes the essential data layer for the future of AI-driven DevOps. With the recent launch of our CloudBees MCP Server, we are building the bridge that allows AI agents to securely and intelligently interact with your entire SDLC.

The age of choosing between developer freedom and enterprise control is over. The era of being forced into rigid, opinionated platforms is ending. We believe in a new way forward—one that embraces your investments, empowers your teams, and prepares you for an intelligent future.

This is not the age of the platform. This is the age of unification.

To learn more, visit: https://www.cloudbees.com/
October 16, 2025
The Quantum Shift Is Here: A Survival Guide for the New Era of Software

The job of a modern software professional has changed. It now seems to include everyone else’s.

Overnight, developers, security professionals and DevOps engineers have been asked to become cloud architects, AI whisperers, security sentinels and compliance officers. This isn’t just “shifting left.” It’s a total gravitational collapse where the entire business—its innovation, its revenue, its risk—now orbits the software supply chain. This new reality is the Quantum Shift, a fundamental change that demands new thinking. This is the central challenge we are taking head-on at swampUP 2025.

The Unsustainable Weight of Complexity

The pressure on engineering teams stems from the explosion of tools and methodologies we’re experiencing. We’ve passed a threshold in the movement from monoliths to microservices, increasing the number of components these teams manage by orders of magnitude. Each component has its own lifecycle, its own dependencies, its own vulnerabilities. To manage this, teams now operate a sprawling ecosystem of systems for source control, continuous integration (CI), security scanning, and artifact management (with Artifactory of course!). The cognitive load of constant context-switching is immense.

At the same time, security and compliance demands have become relentless. Modern applications are primary targets. Development and security teams are on the front line, expected to generate SBOMs, verify the integrity of every open-source package, and provide evidence of secure practices. An auditor’s request can halt development for days as they manually piece together data from a dozen different systems. This is an inefficient and frustrating use of their engineering skills.

Why Throwing More Tools at the Problem Fails

The instinctive response to this complexity has been to buy more tools. A new scanner here, a separate workflow tool there. But this approach can only, obviously, make the problem worse. Each new tool is another dashboard to check, another silo of data, or another integration point that can fail. Teams lack a single source of truth. They cannot see the full lifecycle of a component from a developer’s first commit to its final deployment. This gap in visibility is a major source of risk and inefficiency. Engineers spend more time managing the tools than creating value for their customers.

The Human Element in a World of Automation

The Quantum Shift isn’t just about tools; it’s about the role of the modern engineer. There’s a palpable fear in our industry about automation and AI taking jobs, so let’s confront that. I don’t believe these tools are here to replace software professionals. They are here to amplify them. Think of the leap from hand tools to power tools. A master carpenter with a handsaw was a craftsman. But with power tools, that same person could build a house. The craft wasn’t lost; the scale of impact was magnified.

This is our power tool moment. The professionals who master this new reality—who learn to manage complexity and leverage automation—will become the new leaders, delivering the impact of an entire team.

The Case for a Unified Platform

The solution is a unified platform, a central system of record for every software component. This single source of truth gives teams complete visibility, allowing them to trace a vulnerability from production back to a specific line of code in moments. It automates security and compliance checks within the workflows their developers already use, reducing their cognitive load.

This unified approach requires a strong ecosystem. At swampUP, we’re assembling an alliance of the industry’s brightest minds to show how it’s done. Attendees will hear from leaders at NVIDIA, ServiceNow, Sonar, and GitHub, all focused on a single mission: providing a real-world roadmap for building an integrated, secure, and efficient software supply chain.

Where We Solve These Problems, Together

If engineering and security leaders are tired of the massive, impersonal tech carnivals, swampUP is the antidote. We keep the event small, focused, and rooted in authenticity. We are returning to Napa to create an environment for real conversations with industry peers.

People often ask what our CEO, Shlomi Ben Haim, would say is the true purpose of this conference. He’d tell you it’s his favorite day of the year because its mission is simple: pain solving. That’s not a buzzword. It’s a promise. It means we’re not here to sell something; we’re here to articulate the pain a team is feeling right now and give them a direct, practical answer. Attendees won’t see slideware about what might be cool in sixteen years. If a team is struggling with a problem today, we want to fix it. This philosophy is about solving real problems, making solutions practical, and staying grounded in the reality of everyday business.

That’s why the event starts with a full day of deep, hands-on training where attendees will build solutions, not just watch presentations. It’s why our keynotes feature new products they can use immediately. It’s about making a real difference in the work lives of software professionals.

The Quantum Shift is the biggest challenge and the greatest opportunity our industry has ever faced. The shift is happening with or without you.

Join us at swampUP 2025, and let’s lead it together.

swampUP 2025 takes place September 8 to 10 at the Meritage Resort and Spa in Napa, California. Registration is open at swampup.jfrog.com.

The Techstrong team will be on site speaking with industry leaders and attendees to bring you on-the-ground perspectives from the event.

August 26, 2025
Breaking Through – Beating Mainframe Delivery Bottlenecks
The mainframe powers large – and vital – elements of the global economy. Mainframe DevOps and new innovations offer the potential for delivering greater value, faster. Yet market data suggests significant challenges in achieving it. What can be done to beat the bottlenecks in mainframe delivery?

The Mainframe: Powering the Future of Enterprise Computing

The mainframe market comprises thousands of well-known, successful organizations and institutions worldwide. These organizations span the financial services, insurance, retail, logistics, transportation, and government sectors, among others, serving millions of clients. Their IT infrastructure is among the most active, processing billions of transactions as they support vast areas of the global economy.

The core business systems of these organizations rely on the IBM mainframe, which is considered by reputation to be the most powerful and resilient machine available.

To learn more about the mainframe market and the opportunities—and challenges—it faces today, PopUp Mainframe recently commissioned a survey, conducted in 2025 by market researchers Vanson Bourne.

The survey revealed overwhelming loyalty to the mainframe platform and a positive outlook regarding the opportunities Linux provides on the mainframe by using the specialist processor IFL. The market responses showed a clear commitment to the mainframe, now and into the future:
- 98% rely on the IBM mainframe to run their organizations
- 94% confirm their potential to leverage additional workload capacity on specialist/Linux environments on Z
- 97% seek to increase the use of specialist mainframe processors
The Challenges Ahead

The same survey, though, highlighted areas of concern. Organizations face significant operational challenges across the mainframe delivery process. Nearly all respondents encountered difficulties during development and testing phases using the mainframe. Concerns over the availability of mainframe environments were widespread, while a third of respondents required four or more teams to complete mainframe deliveries. Additionally, 80% cited staffing and tooling limitations as hindrances to business operations.

The research further emphasized five strategic areas where the mainframe environment struggles to meet aspirations: cost efficiency, flexibility, speed of delivery, risk management, and sustainability. More than 80% of respondents indicated that improvements were needed in each area.

Addressing the Bottlenecks

PopUp Mainframe offers an innovative solution to these bottlenecks and their strategic impacts. It’s instantly available mainframe environment supports development, testing, training, and other typical mainframe activities, accessible with the click of a button. Functionally equivalent to mainframe z/OS, it runs on the customer’s choice of hardware, enhancing availability and usefulness.

PopUp addresses key bottlenecks head-on: in an ideal mainframe scenario, everyone involved in the SDLC—analysts, programmers, QA staff, business users, administrators, DBAs—logs into the mainframe to perform their tasks in sequence. However, in reality operational complexities and restrictions often hamper innovation and impede mainframe delivery. PopUp Mainframe addresses these complexities and provides instantaneous resources for those who need them by enabling dev, test, and training activities in a compatible, virtual mainframe environment.

Cornerstone Capabilities

PopUp Mainframe ensures compatibility with the mainframe z/OS environment it replicates. Key product highlights include:
- Integration with mainframe environments and tools, including IBM, BMC, third-party, and open-source DevOps tools.
- Full compatibility with z/OS applications.
- Support for data compliance and regulation using advanced masking technology, with the option to keep data on the mainframe.
- Easy access and availability, with environments up and running in minutes, supporting IT sustainability goals.
- Universal usability, accommodating both ISPF access and GUI IDE tools simultaneously.
PopUp Mainframe acts as a virtual mainframe environment, designed to support each organization’s unique selection of tooling for mainframe application delivery processes. To do so, the product will integrate with a wide variety of popular mainframe toolchain elements. For example, PopUp Mainframe supports mainframe DevOps setups using VS Code or IDZ as the developer IDE, and open-source tools like Galasa and COBOL Check for unit testing, with orchestration tools such as GitHub managing these processes.

Fully flexible and scalable, the solution allows organizations to deploy as many PopUp Mainframe instances as needed. Two editions of the PopUp Mainframe product are available: Z edition (Linux on Z or LinuxOne installation) and X edition (x86 on premise or cloud installation).

Revolutionary Results

The opportunity for improvement by using PopUp Mainframe is both instantaneous and significant: one client demonstrated the solution’s efficacy by completing a POC in a single afternoon. Another client significantly improved delivery speed by several hundred percent. Other observed outcomes show PopUp Mainframe has helped clients meet several strategic goals:
- Accelerate development and testing while protecting production MIPS.
- Initiate development, testing, training, and R&D projects flexibly and quickly.
- Quadruple mainframe deliveries through efficient resource usage.
- Ensure data compliance in mainframe testing by keeping data on Z.
- Enhance sustainability and reduce emissions by deactivating unused environments.
Futurum Research Perspective

“Hosting critical time- and availability-sensitive business functionality on the mainframe remains a vital part of IT in the enterprise and much of the public sector,” said Guy Currier, Analyst, The Futurum Group. “But change management on the mainframe can be slow and inefficient, especially as business complexity and regulatory pressures increase. Innovative technologies such as PopUp Mainframe offer mainframe teams opportunities to accelerate the delivery velocity of their business-critical systems.”

Learn More

Watch our recent devopsy.kinsta.cloud webinar on demand to learn more about this topic. We will also be presenting at the forthcoming Tech Field Day Extra at SHARE Cleveland 2025 on August 19-20.

For further information, datasheets, and release highlights, visit the PopUp Mainframe website.
June 25, 2025