An oil trader prices tomorrow’s cargoes on a model someone on the desk built last year. A pipeline scheduler moves product through an application written fifteen years ago by an engineer who has since retired. A reservoir engineer asks an AI assistant for a script and has it running by lunch. None of this software was ever sold to a customer, and all of it keeps a very large business running.
Almost none of it was written by a professional software engineer, and that is the part most security programs miss. Energy companies have quietly become software companies that are staffed by people with other job titles, and AI assistants are accelerating their output with every passing quarter. Securing that software is a different problem from securing a product company’s codebase, and the difference shapes everything that follows in this guide.
Key Takeaways
- Most new code at energy companies comes from citizen developers, trading desks, and AI assistants rather than professional engineers, so security controls need to attach to the code path instead of the job title
- No regulation, NERC CIP included, requires an energy company to secure its internally written software, which means adoption runs through internal architecture and governance panels rather than compliance mandates
- Small security teams covering thousands of repositories can only succeed with automated discovery, AI visibility, and exploitability-based prioritization, because manual review fails on arithmetic at AI-era code volume
What Makes Application Security Different in Energy
Application security in energy is shaped by scale, not by regulation. Two realities define the sector, a codebase too large for manual review and a development culture too decentralized for a central inventory, and this section takes each one in turn.
One question, thousands of repositories
The scale problem is easiest to see through one ordinary task. A security engineer at a large energy company can be responsible for thousands of repositories spread across dozens of source control organizations, secured by a team small enough to fit in one meeting room. When a widely used dependency ships a serious vulnerability, the first question is simple. Which of those repositories are exposed? Answering that question is where the trouble begins.
It usually means writing a script that sweeps every organization one by one, waiting hours for the sweep to finish, and hoping the platform rate limits hold long enough to return a complete answer. That is the felt problem in this sector. It is not a breach on the front page. It is the inability to answer a basic exposure question quickly across an environment that grew up piecemeal over decades.
Decentralized development with no central map
Development in energy is decentralized and business led. Repositories accumulate wherever a team happened to stand one up, and no single group holds the full map of what exists. Central visibility, or the lack of it, is the trigger that starts most platform evaluations in this sector, because every downstream security activity depends on knowing what the company actually has before anyone can secure any of it in a systematic way.
This guide works through what software energy companies actually build, who writes the code that needs securing, why manual review cannot keep pace with AI-era volume, how security tools get approved in this sector, where the honest limits of current tooling sit, and what an energy company should require from a platform before committing to one. In energy, the case for application security starts with one unanswered question. Which repositories are exposed right now?
What Software Do Oil, Gas, and Utility Companies Build?
Oil, gas, and utility companies build far more software than most people outside the sector assume, and almost all of it is internal. Subsurface interpretation tools, drilling optimization models, production surveillance dashboards, trading and scheduling systems, pipeline measurement and reconciliation applications, and grid and customer platforms all get written in house, because no vendor product fits the specifics of a given field, pipeline, or service territory. The footprint differs by segment, and so does the reader.
| Segment | Software footprint | What it means for security |
|---|---|---|
| Upstream oil and gas | Internal tools for subsurface interpretation, drilling optimization, production surveillance, trading, and scheduling | Large citizen developer populations and decentralized, business-led teams, often with no named AppSec identity |
| Oilfield services | These companies sell technology, so they build far more software than the operators they serve | Real, named AppSec programs, and the most mature and most skeptical readers in the sector |
| Midstream pipelines | Measurement, reconciliation, scheduling, and nominations systems that are old and load bearing | Very small development teams relative to codebase size, where availability dominates every conversation |
| Electric and gas utilities | Grid and customer platforms, plus a young and growing internal development practice | A newly built AppSec function seeking central visibility for the first time |
The common thread across all four segments is age. These are old industries running a great deal of old technology, and a scheduling application written fifteen years ago is still moving product today while the person who wrote it may have retired. The software estate that needs securing was never designed as an estate. It accreted, one business problem at a time, and the inventory of what exists is usually incomplete.
Any security program in this sector has to begin from that reality. The software an energy company builds is old, internal, business led, and only partially mapped, and a program that assumes a clean, modern, centrally owned codebase will stall in its first quarter. A guide, a platform, or an internal pitch that starts anywhere other than this inventory problem is answering a question the sector is simply not asking.
Who Writes the Code That Needs Securing
The honest answer is that most of the code an energy company produces today does not come from its professional software engineers. It comes from everyone else, and the four groups below explain where the growth is.
Professional developers work inside the process
Professional developers at energy companies are, for the most part, fine. They work inside a defined development process, commit to known repositories, run code through pipelines, and accept security controls as a normal part of shipping software. Where a mature engineering organization exists, as it does at most oilfield services companies, the standard application security toolchain already reaches these teams and does roughly the job it was designed to do.
A guide that treats these teams as the risk misreads the sector, and so does a security program. Professional engineers are the population existing controls were built for, and the controls mostly work on them. Conceding that up front matters, because it signals to a skeptical practitioner that what follows describes their actual reality rather than a manufactured threat, and it clears the way to talk honestly about everyone else.
Securing citizen developer and low-code applications
Citizen developer programs in energy are formal, funded, and publicly promoted. Reservoir engineers, production analysts, schedulers, and finance staff are actively taught to build enterprise applications with low-code platforms and, increasingly, with AI assistants that let them prompt for code rather than write it. The sector has its own word for the newest version of this, vibe coding, and the applications it produces run real business processes inside these companies every day.
These builders have no application security training, and nobody expected them to have any. No single citizen-built application is the issue. The trouble starts with volume, because thousands of applications appear across the business, each with its own dependencies, and when a common library ships a zero day nobody can say what the exposure is. Most sit outside the inventory the security team can see, and the risk lives in the absence of guardrails, not in the builders themselves.
Governing AI-assisted development outside engineering
The most sector-specific dynamic involves revenue-generating teams. Commercial and trading groups have adopted AI coding tools ahead of formal approval, and energy is no exception, because the incentive gap is stark. The sanctioned route to a new tool can take months, while an AI assistant produces a working script in a day. A team measured on revenue does not wait months for a one-day alternative, and the business tolerates the workaround because the revenue involved dwarfs the perceived risk.
This is worth stating plainly, because it dictates the shape of any workable program. Refusal is not an available control. A policy built on saying no has already failed, because the people it addresses have both the means and the motive to route around it, and their management will side with them. The realistic goal is a sanctioned path fast enough that the workaround stops being worth the effort, with visibility over whatever gets built either way.
How AI changes the volume problem
AI assistants did not create the citizen developer. They removed the last barrier, because a person who can describe a business problem but cannot write code can now produce working software in an afternoon. Coding agents push this further still and are beginning to commit code as contributors in their own right, which means code volume now grows faster than any review process a company could reasonably staff or fund.
The people producing the most of this new code are also the least equipped to secure it, and that combination defines the era. The question facing an energy security team is no longer whether these tools get used, because that decision has already been made across the business. The question is whether the code they produce lands somewhere the security team can see, and everything else in a program follows from that answer.
Securing Code That Never Reaches a Repository
Some of the code being written at energy companies today never reaches a repository at all, and this is the hardest problem in the sector. Field staff and commercial staff write scripts in a local editor, run them from a laptop, and store them in personal cloud folders. There is no repository, no pipeline, no scan, and no owner of record, and nearly every control a security team operates assumes code eventually gets committed somewhere.
The population producing uncommitted local code is also the population growing fastest, because AI assistants make local scripting easy for people who never scripted before. This code carries the same secrets, the same dependencies, and the same business logic as anything in a repository, with none of the usual oversight. Some approaches reach part of the problem, and each one is worth deploying with clear eyes about its real limits.
- Endpoint and editor controls can observe and govern some of what gets written locally, before any commit happens.
- Guardrails placed inside the AI tools and editors people already use catch issues at the moment of creation rather than at review.
- Making the sanctioned path faster and easier than the local workaround pulls more of this work into repositories where normal controls apply.
None of these fully solves it, and it is worth being direct about that, because the sharpest readers in this sector will test any claim to the contrary. Uncommitted local code remains a partially open problem across the industry, and pretending otherwise is the fastest way to lose a technical audience. A vendor or an internal champion who admits the gap openly will be trusted on everything else they say, and one who papers over it will not.
Scaling Coverage to Small Teams and Large Codebases
The scale problem in energy application security is an inversion, a very large codebase watched by a very small team. That mismatch plays out in two ways, in the arithmetic of review and in how platforms are priced and deployed.
Code volume outruns manual review
The numbers describe the mismatch better than any argument could. The codebase is enormous, spanning thousands of repositories across dozens of source control organizations, and the team securing it is tiny. A company may employ hundreds of people across all of security while staffing application security with a handful, and AI-assisted development now produces code faster than that handful can read it, let alone review it with any real care.
The first consequence is that there is no headcount answer. A program that requires a human to review code at AI-era volume fails on arithmetic before it fails on anything else. The real decision is which few judgments genuinely still need a person and which get automated, and a program that never makes that decision explicitly ends up making it by accident, with the ungoverned remainder growing quietly every quarter.
How pricing and legacy compound the problem
The second consequence involves commercial structure, and it deserves careful rather than combative framing. Pricing models tied to lines of code or to developer seat counts assume a rough proportion between codebase size and team size, and energy breaks that assumption completely. A huge, decades-old codebase maintained by very few people gets punished by that kind of model, so the pricing structure of a platform matters as much as its feature list for this buyer.
Legacy reality compounds the arithmetic. On-premises source control, older IDE installations, .NET-heavy codebases, and unstructured infrastructure code are the norm in this sector rather than the exception, and each one adds friction to every scan and every rollout. A security team of five covering a codebase built over twenty years can only succeed with automation, and the honest planning question is which decisions still deserve a human rather than how to review everything.
How Security Tools Get Approved in Energy
In energy, application security adoption is driven less by external regulation than by internal governance. The path to approval runs through review panels rather than compliance mandates, and knowing how those panels work is half the job of getting a tool adopted.
The gates and the evidence they expect
Start with a clear view of what the approval gates are in practice. No regulator requires an energy company to secure the software it writes for itself, and the gates that actually decide whether a tool gets adopted are internal. New tooling passes through architecture review panels, security architecture forms defended in front of a review board, baseline internal security requirements, and, for anything involving AI, due-diligence assessments that pull in the legal department.
This changes what an internal champion is actually doing. In a regulated context, the champion cites the mandate and the conversation moves to cost, but in energy there is no mandate to cite. The champion is assembling evidence to convince a panel of skeptical senior architects that a problem exists, that it is growing, and that the proposed tool addresses it without breaking anything the company depends on. Every section of this guide is written for that room.
Utilities, legal review, and the limits of regulation
Utilities add one nuance that surprises people arriving from other industries. For AI adoption specifically, the bottleneck is frequently the legal department rather than the security team, working through vendor due-diligence review before anything gets switched on. A champion at a utility should know before the first meeting that legal will be in the room, should budget calendar time for that review, and should treat the whole sequence as a planning fact rather than an obstacle.
Regulation deserves one honest paragraph, and only one. Cybersecurity rules exist in this sector, they matter at the margins, and none of them requires securing internally written business software, so building the case on regulation that does not apply is the fastest way to lose a panel. The gate that matters is internal, and the champion who prepares for the panel rather than searching for a mandate is the one who ends up with approval.
Application Security on a Microsoft-Centric Stack
Most application security tooling assumes a stack that energy companies do not run. The common pattern in this sector is on-premises Azure DevOps rather than cloud-hosted Git, licensed Visual Studio rather than lightweight editors, deeply .NET-heavy codebases, and AI model access routed through a cloud provider’s AI platform rather than through a model vendor directly. A tool that assumes the modern default stack has already made four wrong assumptions about this buyer.
Integration assumptions break quietly, which is why this matters. A tool built around a hosted Git service, a specific editor, and direct model APIs will demo well and then fail during a pilot on the stack the company actually runs, and many teams in this sector have been burned by exactly that sequence. A reader evaluating platforms should ask about on-premises source control support and .NET coverage in the first conversation, not the fourth.
Tool rationalization adds pressure from the other direction. Energy companies own large security stacks, their leadership is pushing to consolidate, and a new platform is easier to defend when it replaces two or three existing tools than when it lands as one more line item on a crowded budget. The practical test for any new tool in this sector is whether it fits the stack that exists and shortens the tool list rather than lengthening it.
Governing Shadow AI and AI Spend
Shadow AI reaches energy companies through two doors, unsanctioned coding tools in oil and gas and vendor AI features in utilities, and the spend behind both is just as invisible as the risk. Getting a governance case funded starts with seeing the whole picture.
How shadow AI shows up in each segment
The two forms look nothing alike in practice, which matters for anyone building the case. In oil and gas, shadow AI mostly means coding tools, brought in by citizen developers and revenue teams unwilling to wait for the sanctioned route. In utilities, shadow AI arrives mainly as vendor SaaS products with AI features switched on, and the pressure point is the legal team running due diligence rather than the security team running scans.
The visibility question differs accordingly. An oil and gas security lead needs to know which assistants and agents are writing code across the business, while a utility lead needs to know which vendors have quietly switched on AI features and what data those features touch. Both are inventory problems at heart, and neither can be answered by a survey, because the people using unsanctioned tools have little incentive to raise their hands.
Why cost is the argument that lands
Cost is the framing that opens doors. AI spend control comes up unprompted in this sector, because nobody can say with confidence how many AI tools are in use, who is paying for them, or whether three teams are separately buying the same capability. Mapping shadow AI across the development lifecycle answers the finance question and the security question with the same telemetry, because one inventory of tools, models, and usage serves both at once.
That dual use is the practical argument to lead with. A champion who opens with cost governance and central visibility gets a hearing from executives who would tune out a threat briefing, and the security value arrives as a bonus rather than as the ask. The same inventory that tells finance what the company spends on AI tells security where ungoverned code is coming from, and that case survives a skeptical panel.
What to Look For in a Platform for Energy
An application security platform for an energy company has to fit the sector’s specific shape, which means fragmented and partly on-premises infrastructure, a huge legacy codebase, a small security team, and a fast-growing population of non-engineers producing code. The criteria below follow directly from those constraints, and any platform under evaluation should be tested against each one in writing, because vague answers in a sales cycle become integration failures in a pilot.
- Discovery and inventory across fragmented and on-premises source control, because a platform that only sees cloud-hosted repositories misses much of the estate in this sector
- Coverage that attaches to the code path rather than to the developer role, so code from citizen developers, traders, and AI assistants is governed by the same controls as code from engineers
- Visibility into AI tools and AI-generated code, including which assistants and models are in use, where AI-written code is landing, and what all of it costs
- Secrets detection that scans repository history as well as current state, because credentials committed years ago remain live risks in long-lived codebases
- Prioritization by exploitability and reachability rather than by raw severity counts, because a small team cannot triage tens of thousands of findings and needs to know which few genuinely matter
- Deployment that fits a Microsoft-centric and partly on-premises stack, including on-premises Azure DevOps, .NET-heavy codebases, and AI access routed through a cloud provider
- A commercial model that does not penalize a large codebase maintained by few developers, since pricing by lines of code or by seat count punishes the exact profile most energy companies have
Two of these criteria deserve extra weight in this sector. Coverage that follows the code path is the difference between a program that governs all code and one that governs only what professional engineers write, and the second category is the one growing. Prioritization depth is the difference between a platform a five-person team can operate and one that buries them, because raw finding counts are a burden rather than a service at this scale.
A useful evaluation exercise is to score each candidate against these criteria before any demo, then ask the vendor to show evidence for the two or three weakest scores. A platform that meets these criteria fits energy, and a platform that fails more than one of them will struggle in this sector no matter how well it performs elsewhere, because the constraints described throughout this guide do not soften for a good product.
How to Build the Program
A workable application security program in energy is automation first and adoption first, because staffing is the binding constraint and failed rollouts are a live memory at most companies in this sector. The five moves below give the program its shape, and the order is deliberate, because each move creates the conditions the next one depends on. A team that runs them out of sequence usually ends up scanning repositories it cannot inventory and shipping controls nobody adopts.
- Start with inventory, not scanning. Discovery across every source control organization comes first, including the fragmented and on-premises ones, because inventory is the thing that fails for organizational reasons. Development here is decentralized and business led, and no scanning program can cover repositories nobody knows exist.
- Govern by destination, not by author. Apply one set of controls to anything that reaches a repository and a pipeline, whether it came from a platform team, a reservoir engineer, a trader, or a coding agent. Controls attached to job titles miss the fastest-growing sources of code entirely.
- Decide deliberately what gets a human. At the current ratio of code to reviewers, automation is arithmetic rather than preference. Name the specific decisions that keep a person in the loop, automate the rest explicitly, and accept that anything in neither category is currently ungoverned.
- Make the sanctioned path faster than the unsanctioned one. Put guardrails in the editors, command lines, and AI tools people already use, because a control that requires opening a separate console will not be adopted by people who never asked for security tooling in the first place.
- Treat rollout as the hard part. Handing a team a tool and telling them to use it is the documented failure mode in this sector. Budget for adoption, training, and change management with the same seriousness as procurement, because a shelved tool secures nothing.
The sequence matters as much as the list. Inventory before scanning, destination before author, and adoption before expansion give a small team a program that compounds, because each quarter of coverage makes the next quarter cheaper. A program built in this order survives contact with a decentralized company, and a program built in any other order usually does not, which is a lesson most energy companies have already paid to learn once.
What Regulation Actually Requires
Cybersecurity regulation touching the energy sector is real, and it is narrower than most people inside these companies assume. The frameworks in the table below come up in nearly every internal conversation about security tooling, usually raised by someone who believes one of them requires the program under discussion. None of them does, and knowing exactly what each one covers keeps that misunderstanding from derailing an otherwise straightforward approval conversation.
| Framework | What it actually covers |
|---|---|
| TSA Security Directives | Cybersecurity requirements for designated critical pipeline owners and operators |
| Pending TSA rule for surface transportation | A proposed rule formalizing cyber risk management requirements for pipeline and rail operators |
| API 1164 | A standard for pipeline control systems and their operational environments |
| NERC CIP | Reliability standards for the bulk electric system, applying to grid operations |
| SEC incident disclosure | Requirements for public companies to disclose material cybersecurity incidents |
None of these frameworks requires an energy company to secure the software it writes for itself. NERC CIP governs grid operations rather than internal business applications, and the pipeline directives address designated operators and their control environments. Where a practical reference genuinely helps, NIST SSDF and OWASP guidance are the ones practitioners in this sector actually use, and regulation belongs in the appendix of the internal case rather than at the front of it.
How Cycode Fits
Everything above describes the problem as energy security teams actually experience it, including fragmented inventory, ungoverned AI code, and a findings volume no small team can triage.
This section maps those problems to what Cycode does, because the fit is direct, and because a champion carrying this guide into a review panel will eventually be asked which platform answers the case it makes. The table pairs each problem with the capability that addresses it.
| Problem established in this guide | Cycode capability |
|---|---|
| Cannot answer which repositories are exposed across a fragmented estate | Platform-wide discovery and inventory across source control and CI/CD, including on-premises systems |
| Citizen developers and vibe coders working outside any defined workflow | AI Guardrails at the IDE, the command line, and inside AI coding tools, so controls attach to the code path rather than the job title |
| No visibility into AI tools, AI-generated code, or what either costs | AI Visibility for shadow AI, coding assistants, and MCP servers, with AI Governance and a live AIBOM |
| Secrets sitting in automation scripts and integration code | Secrets detection across repositories, pipelines, and full commit history |
| More findings than a small team can triage | The Context Intelligence Graph, the AI Exploitability Agent, and the Change Impact Analysis Agent, which reduce raw findings to the few that are genuinely exploitable |
| Whether a chain of weaknesses reaches something that matters operationally | Attack chaining, which connects individual weaknesses into paths and shows which paths reach significant systems |
The last row of the table is the reframe that matters most for an energy reader. A list of forty thousand findings is useless to a five-person team, while a short list of exploitable paths to systems the business depends on is a work queue, and moving a program from the long list to the short one is most of what a platform is for at this scale, whatever else it also does.
On uncommitted local code, guardrails at the editor and inside AI tools reach part of the problem, and part of it remains open across the industry, exactly as the earlier section on code that never reaches a repository describes. Cycode’s fit for energy comes down to seeing the whole estate, governing every code path regardless of author, and shrinking the findings list to the few items a small team can genuinely act on this quarter.
