Security, better late than never

Last month, an old colleague and friend, Theo, reminded me that it was the 16th anniversary of the day Theo and I started working together. The internship was at Colombia’s largest insurance company. It was a dream job. Lots of learning. Long days and late nights juggling production incidents, bug fixes, angry users, and disappointed bosses. It has been a long career. Theo also called me with an assignment for a US customer. He asked me to perform a high-level security assessment of an AWS organization. The company is in the midst of a merger and wants to tighten its environments beforehand.

If the call had not started with the anniversary reminder, I would not be writing this post. Right after hanging up, I could not avoid thinking about the motivations behind this cloud security assessment.

I kept asking whether the company was doing this assessment merely because of the merger, whether it would have done it otherwise, and why security tends to be delayed. I also wondered why so many software and operations engineers take security for granted, or, more precisely, cannot imagine a hack happening during their tenure.

I realized that these questions had lingered for at least 12 years. I am cutting myself some slack for my first four years of work, when I was overwhelmed by so many moving pieces that security became a dark art performed by shady hackers in hoodies.

Neglecting security

I searched my memories of jobs and projects and noted the pattern. Security is a commonly neglected non-functional requirement (NFR) in software engineering. It is common to think that implementing authentication and user management ticks the checkbox. Adding roles to the system ticks another checkbox, and publishing the website with HTTPS ticks the last one. Security goes far beyond this and must be treated as a multilayered architectural discipline. Security NFRs can be broken down into domains, or, more precisely, operational domains.

• Authentication and identity management: Verify who accesses the system.
• Authorization and access control: Define what a verified user or service is allowed to do.
• Data privacy and cryptography: Protect sensitive data in transit and at rest.
• Auditability: Track and attribute system activity for forensics and compliance.
• Supply chain and dependency security: Protect software from third-party libraries, open-source packages, and build tools.

I have written software that ran on-premises and on public cloud infrastructure, and I have operated infrastructure in the public cloud. I know how differently software engineering teams approach security. On-premises, developers work with more restrictions and are less involved in lower-level security operations. In the cloud, developers gain more freedom, which comes with responsibility for their environments’ security operations: data encryption, HTTPS certificates, firewall rules, patching, disaster recovery, and network segmentation, among others. In many cases, teams misinterpret the shared responsibility model with cloud providers, resulting in vulnerable environments because someone assumed that the provider had taken care of a control. When this happens, it creates hidden risks for organizations. Engineers must build a culture where risks are raised and acknowledged, then assessed so the organization can decide whether to mitigate, accept, or remediate them.

Risk assessment tells you what you need to protect (secure) and why. Cloud security provides the tools and controls on the how.

I have been part of teams on both sides of the same coin, and I can confirm that security is not the top priority across software engineering roles. I do not think there is only one answer. I want to lay out my view on a topic that has gained relevance within organizations because of accelerated AI adoption.

Why security falls to the bottom of the backlog

Theory 1: the abandoned security tool

Someone some time ago turned on a security tool, say AWS Security Hub, and the overwhelming amount of failing controls became part of the landscape.

That person is no longer around, and nobody can explain why the score is so low or what it says about the organization’s security posture.

Ideally, before provisioning and deploying to the cloud, a risk assessment identifies potential threats and business impact, then dictates which cloud security controls are mandatory. Without this, the failing controls tell you nothing.

Theory 2: security without a definition of done

Missing a risk assessment and cloud security strategy creates a sense that the work lacks tangible value and a definition of done.

Engineering teams are trained to deliver value. Implementing a security initiative without clear stakeholders, a roadmap with milestones, and continuous monitoring to close the loop lowers motivation. A senior engineering team brings a foundational set of security practices by default. However, a lack of vision for the organization’s overall security posture eventually contaminates even the most skilled and experienced team.

Theory 3: the organization is not a target yet

The organization is not big enough, so it is not a target yet.

This was a valid rationale a decade ago, when compute was more expensive and available resources were used by unethical actors to target enterprises and large companies. In today’s agentic AI world, bots and other workloads can scan indiscriminately. A well-defined cloud security strategy is imperative for survival.

What moves security to the top of the backlog

After understanding the reasons behind the neglect, I can look at the opposite phenomenon: the triggers that make security a priority.

The traditional reactive approach to software security, which treats it as a final checklist item before release, is breaking down. Four pressures push leadership teams to prioritize security at an architectural level.

1. The software supply chain explosion

• The reality: Third-party components, open-source packages, and external APIs now make up 80 to 90% of a modern application. However, supply chain compromise has surged dramatically, with third-party involvement in breaches doubling and hundreds of thousands of malicious open-source packages injected into public registries such as npm, PyPI, and Hugging Face.
• The wake-up call: An enterprise is only as secure as its deepest transitive dependency. Securing the perimeter of your own codebase is no longer sufficient; organizations must govern what enters their build pipelines at the point of ingestion.

2. CVE Overload

• The reality: Tens of thousands of Common Vulnerabilities and Exposures (CVEs) are published every year, causing severe alert fatigue similar to the failing controls. Worse yet, the timeline from vulnerability disclosure to active exploitation has inverted. Attackers frequently weaponize zero-days and known flaws before patches are publicly available.
• The wake-up call: Traditional patching schedules (like a 30-day or 90-day window) are obsolete. Security teams are forced to adopt automated context-driven prioritization and agentic remediation to neutralize active threats instantly.

3. Smarter AI models and agentic attack surfaces

• The reality: Artificial intelligence has evolved from static text generation to autonomous AI agents that write code, query databases, and execute tool calls via APIs. These agents introduce new threat vectors, such as prompt injection, model data poisoning, and unauthorized API routing.
• The wake-up call: AI tools are active actors with non-human identities. Treating an AI model like a simple database or static library ignores the fact that it can be manipulated to execute unintended logic across your core infrastructure.

4. High-Stakes regulations and AI compliance mandates

• The reality: Regulatory frameworks have shifted from guidelines to legal mandates with strict enforcement deadlines. For instance, the EU AI Act imposes cybersecurity resilience, mandatory tamper-evident logging, and risk management assessments for high-risk AI systems, with severe financial penalties.
• The wake-up call: Security is no longer just an engineering best practice; it is a legal requirement. Compliance can no longer be achieved via manual yearly audits. It demands automated “systems of evidence” embedded directly into the software pipeline.

Security work moves to the top of the backlog when a risk assessment names the assets, the threats, and the controls that matter. Start with the dependencies entering the build pipeline and the non-human identities calling internal APIs. Then record the evidence continuously, so a merger, an incident, or a new regulation does not become the first reason anyone looks at the security posture.