Most enterprises are preparing their security plans for 2027, with budgets approved in December and new initiatives starting in January. Attackers are not working on the same calendar.
The incidents reported in October illustrate this. Crypto exchange Binance lost over $6 billion, with early findings pointing to a compromised DevOps machine as the entry point. LiteLLM, an open-source package, was compromised using a key exposed months earlier. In both cases, attackers appear to have targeted the credentials, tools and pipelines around the applications rather than the application code itself.
These incidents show why enterprises must look beyond application security to the systems that build and deliver software. Five priorities stand out for 2027.
1. Treat software delivery pipelines with the same scrutiny as production systems
Software delivery pipelines rarely feature among an organisation’s most critical production systems, despite having the authority to change what runs in production. Build runners manage secrets, sign artifacts, access cloud accounts and release software to customers.
I see this as a significant gap in enterprise security. Organisations have invested heavily in protecting running applications, while the processes that build and release them have received less attention. TeamPCP’s recent campaign shows the cost. The group targeted the CI/CD pipelines of thousands of organisations and exfiltrated more than 78,000 secrets. Because pipelines hold the credentials that unlock cloud accounts and production, one compromise can reach far beyond one application.
Limiting that exposure requires tighter access controls, greater visibility into pipeline activity and clear separation of responsibilities, so no single identity can introduce a change and approve its release.
2. Address the risks of long-lived credentials at the design level
The LiteLLM incident shows the risk of persistent credentials. A master key was accidentally published in a public repository in May. In October, an attacker used it to publish a malicious release containing credential-stealing software. The release was live for less than two hours, but the key had stayed valid for five months.
Most organisations respond with secret scanning and rotation. Both are necessary, but neither addresses why a credential stays valid long after exposure.
As AI generates more code and agents gain access to more systems, credential management will only get harder. Workloads should use distinct, short-lived credentials limited to specific tasks.
3. Strengthen security across the software supply chain
Modern applications depend heavily on third-party software, including open-source libraries, container images and build plugins. Open-source code now makes up 70% to 90% of a typical enterprise codebase.
Attackers exploit this trust by compromising legitimate packages or publishing malicious versions that can reach many applications at once. A component that was secure at development can also turn vulnerable months later.
Organisationshave to look more closely at the components they adopt. A hardened, minimal base image leaves less to exploit. An accurate dependency inventory matters just as much, because when a vulnerability is disclosed, the first question is always which applications are affected. A dependency firewall adds another safeguard. It screens open-source packages, and the packages they depend on, before they are installed or run, and blocks the malicious ones.
Finding a vulnerable component is only the beginning, and in my experience it is the easy part. The harder work is prioritising and fixing, and I expect auto-remediation of vulnerabilities to take on more of it over time.
4. Focus on agent security
AI agents are moving beyond generating code. They can run commands, access repositories, install packages, change infrastructure and trigger deployments. Unlike traditional software, they decide their next step as they go, and what they read along the way can change that decision. In one reported incident, Forever Security found a poisoned AGENTS.md file, an instruction file that coding agents read and follow, that led an agent to try installing a malicious npm package. It was stopped before any code ran.
The agent did what it was built to do: it read the file in its folder and followed it. Enterprise identity and access management was designed around people and fixed software, and it has little to say about an agent that acts on its own. Enterprises need guardrails around both what an agent can reach and what it can do with that access.
The first guardrail covers what gets in and what gets out. Agents can be manipulated through prompt injection or jailbreaking, and they can leak sensitive data unnoticed. Anything an agent reads from outside should be treated as untrusted, its interactions watched continuously, and credentials, source code and customer data kept inside approved boundaries.
The second covers how far a mistake can travel. Each agent should have its own identity, a named owner, permissions limited to the task and a record of what it did. Agents that run code belong in isolated sandboxes, so a bad decision stays contained. Risky actions should wait for human approval, and someone needs to be able to stop an agent immediately. Overall, I believe an agent’s autonomy should never exceed an organisation’s ability to monitor, control and contain it.
5. Remediation at machine speed
Security scanners identify more vulnerabilities than engineering teams can realistically address, while AI shortens the time between discovery and exploitation.
Security teams have traditionally been measured by the number of vulnerabilities they identify. The better measure now is how quickly those vulnerabilities are remediated and patched in production, starting with the ones that are reachable in running software, exposed through APIs or already being exploited.
I expect leading organisations to give remediation speed the same attention as release speed. As response windows shrink, that capability will increasingly determine security effectiveness.
All five priorities come back to one question: how does software move from commit to customer, and who or what can change it along the way?
As delivery becomes more automated, organisations need visibility into where risks emerge, tighter control over access and the ability to fix vulnerabilities quickly.
Authored by Naresh Agarwal, SVP & Head of Engineering, Application Security Platform, Harness
