For years, many companies have operated on a quiet assumption: nobody is coming for us. Someone else is the bigger target, the more obvious payday, or the easier way in. An attacker would have to spend weeks of skilled, manual effort to get into our systems, and we’re not worth the trouble.
That assumption held up because it was a math problem. Effort on one side, payoff on the other. When the effort ran high enough, the shortcuts you took stayed survivable.
AI collapsed one side of that equation. The work that used to take weeks now takes a prompt, which means the calculation that kept you off the list no longer runs in your favor. Your code never changed; the price of attacking it did.
That shift lands hardest on software written long before any of this existed, built by teams who made reasonable decisions under a threat model that has since expired. Here is what changes for those teams, and the controls worth putting in place first.
Summary
The controls that hold up now are unglamorous: keep packages current, wait a few days before adopting a new release, and vet dependencies as an ongoing discipline rather than a one-time clearance. Enforcement belongs in the CI/CD pipeline, where a failed build forces a decision that an ignored alert never will, with automated AI code review running ahead of human review to catch chained vulnerabilities across files. Point that same analysis at your own codebase on a schedule, because attackers already are.
The Barrier to Entry Fell, and Your Risk Profile Moved With It
Attackers run the same cost-benefit analysis defenders do. Both weigh time and skill against payoff, and for a long time that calculation protected many companies simply by making them inconvenient. Inconvenience is not a defense anymore.
“The barrier to entry is so low now,” said Steve Anderson, Principal Developer and AWS Architect at Slingshot. “A lot of people took shortcuts before because they thought ‘we’re just a mid-size company, nobody’s really going to target us.’ The targets that get picked now could be just about anybody.”
Steve pointed to the clearest example: “Writing specific tooling geared toward a particular application used to take a lot of time,” he said. “If you had to handwrite that stuff, it would take forever, and the juice wouldn’t be worth the squeeze. But AI’s lowered the bar on the effort level it takes, so those lower value targets are now something you might go after.”
Doug Compton, Slingshot’s Director of AI Engineering, framed the escalation in familiar terms. “Before, you had script kiddies: people who weren’t true hackers but found scripts out on the internet they could run,” he said. “Now with AI, that’s on steroids. You can prompt AI to go try something quickly and across multiple sites simultaneously.”
The uncomfortable part is what that does to your threat model. You didn’t get more valuable; the cost of coming after you simply collapsed.
Your Dependencies Became the Front Door
Ask most teams where their security risk lives and they’ll point at their own code. The recent wave of supply chain attacks says otherwise.
“Hackers are putting exploits into third-party libraries,” Doug said. “People update to the latest version and pull in the code that has the security issue in it. Their third-party suppliers end up causing the vulnerabilities in their software.”
These libraries are attractive targets for a reason, and it has nothing to do with code quality. Many are maintained by volunteers doing the work as a hobby, which means the people guarding a dependency thousands of companies rely on are stretched thin, underappreciated, and operating without a security team.
That exposure compounds with time. Developers have always let libraries and third-party tools drift a few versions behind, and that drift used to be a tolerable trade. Now it’s the opening.
Which is where there’s some good news for teams running older systems. The upgrade work that used to be impossible to justify has gotten cheap. “Updating to the latest version of a particular framework tends to actually get approved now, because it doesn’t take as long,” Steve said. “They’re pretty quick turnarounds.”
Doug pairs that speed with a simple, almost boring defense: stop treating ‘latest’ as a synonym for ‘safe.’ “One rule of thumb is to wait at least three days to a week before you upgrade,” he said. “Let the new version sit out there for a bit, so if something nefarious happened to it, there’s an opportunity for it to get announced or fixed by then.”
Steve added two more open doors teams rarely consider. The first is letting npm install run binaries, which lets a package you haven’t inspected execute arbitrary code. The second is container images. “If you pull a malicious Docker image and use it in a CI build, that’s also a supply chain attack,” he said. Roll that same tainted image into production, and you have handed someone a path to data exfiltration.
AI Reads Code the Way Attackers Wish They Could
Single-vulnerability exploits are the easy case, since scanners can catch the known ones. The harder case is when three or four unremarkable things line up across a codebase.
“AI is much better at analyzing multi-chained exploits, where it’s not just one vulnerability,” Doug said. “It might be three or four different things working together. Those can span several files, making it hard for a human to remember all the pieces at once. AI puts those pieces together a little more easily.”
Read that again from a defender’s perspective, because it cuts both ways: If an attacker can run a model across your exposed source and surface chained vulnerabilities in an afternoon, you can do the same thing first. The advantage goes to whoever looks harder, and right now, attackers are the ones looking.
The Social Layer Is Part of the Attack Surface Now
The piece of this that has nothing to do with your infrastructure is the one most likely to catch you off guard.
Doug described a case involving a widely depended-on open source library maintained by one person in his spare time. “He noticed a pull request that was very suspicious, and when he decided not to pursue it, he got about a dozen emails from other ‘people’ pushing him to approve it,” he said. “After they dug in further, they found out all those messages were AI. AI submitted a pull request with an exploit, and when it got turned down, it spawned other accounts that emailed the maintainer, pressuring him to accept it.”
An exploit, a rejection, and a coordinated pressure campaign, all automated and aimed at one tired volunteer.
The defenses built to stop that kind of volume are weakening too. “AI’s ability to solve CAPTCHAs now is pretty good,” Steve said. “That just accelerates automated account creation, or makes it easier to accomplish.” The guardrail that assumed bots couldn’t read a distorted word is holding less every month.
Vetting Packages Is a Judgment Call, Not a Checkbox
So how do you decide whether a package deserves a place in your build?
Start with the crowd. “I’d shy away from smaller libraries and stick with ones that have large support groups and lots of users,” Steve said. “Lots of eyes, lots of people doing code reviews. Something malicious is less likely to sneak in, and the quality in general should be better than a solo dev working on it on weekend nights.”
That heuristic holds most of the time, but it has a blind spot worth naming. Download counts measure popularity, not oversight. A package can sit under thousands of production builds and still come down to one person reviewing pull requests on a Tuesday night. Widely used and widely watched aren’t the same thing.
Doug pushes further for anything business-critical. “Depending on how critical it is, doing full code reviews on the software you use is one way to do it, assuming the code is available,” he said. “But so many of these projects use thousands upon thousands of different libraries, so it’s hard to do that. If it’s critical for your company, create a database of which ones have been reviewed and found clean.”
The ceiling is real. Nobody reviews every dependency in a large project. But the handful sitting on your critical path can earn that scrutiny, and knowing which ones you have actually cleared beats assuming all of them are fine.
And Doug wants teams to stop misreading a clean scan. “Just because you run an update on your packages and it says there are no critical vulnerabilities, that doesn’t necessarily mean that’s the case,” he said. “It might just mean nothing has been reported yet; one may get discovered afterward.”
A package marked secure today might not be next week. That’s what makes vetting a discipline, not a decision. You’re not clearing a package once and filing it away; you’re committing to keep looking at something you already approved.
Build the Discipline Into the Pipeline, Not the To-Do List
Everything above fails the same way. Someone sees the vulnerability notice, decides it’s not today’s problem, and moves on. Doug sees it constantly. The alerts fire, and people ignore them.
The fix is to stop relying on attention and start relying on the pipeline. “Your CI/CD pipeline can do a lot of that gathering for you,” he said. “If your pipeline sees on a code commit that a package has changed, it can check how old it is and stop that commit from happening.” Same gate for known vulnerabilities. The build fails, someone has to act, and the decision is no longer optional.
Steve layers automation on top of it. “Dependabot will actually auto-upgrade those packages for you,” he said. “Get a nice test suite in place, and when the packages upgrade and the tests pass, you have more confidence going forward.”
Those two instincts pull in opposite directions, so configure the cooldown instead of letting every new release land the day it ships. The tests tell you the upgrade didn’t break anything; they don’t tell you the package is clean.
Then there is the review step that most teams haven’t added yet. Doug suggests adding an automated AI code review in the deployment pipeline: “It doesn’t replace a human code review,” he said. “But AI is good at finding things a human would overlook, especially when several files interact in a weird way that opens up an exploit. Run the AI code review first, let the developer address those issues, then do the human review after that.”
And it’s worth extending that same thinking past the commit. A monthly security audit of your existing code, run by AI rather than waiting for a human to find the time, catches what shipped before anyone was watching. Static analysis tools like SonarQube have covered part of this for years. The point is that something, human or machine, needs to be evaluating vulnerabilities on a schedule. And it’s best if it’s both.
What Actually Changed
Strip away the new vocabulary and the shift is narrow but sharp: attackers got faster, cheaper, and more persistent. Your software didn’t change, but your assumptions about who would bother coming after it did.
The single most important control isn’t new. It’s almost disappointingly simple: “It’s the same as it was before AI,” Steve said. “Update your packages. There’s just more of it now.”
That one control sits alongside everything else here. Audit your dependencies, treat package vetting as ongoing rather than one-time, remember that social pressure is now part of the payload, let the pipeline enforce what attention won’t, and point the same analysis capability at your own code before somebody else does. None of it is exotic, but all of it assumes you act before you have a reason to.
The advice didn’t change. The consequences of ignoring it did. Patching lagging dependencies has always been the item that slides to the next sprint, the ticket nobody fights for, the work that feels safe to defer because it has been for years. That window closed. The effort to find and exploit what you left sitting there has dropped far enough that someone will get to it before you do.
That is the uncomfortable truth: the defense hasn’t changed. The deadline has.
What Production Actually Buys You
Written by: Savannah Cherry
Savannah leads marketing and new business at Slingshot. She writes, posts, and creates all things Slingshot, and helps companies navigate working with a tech partner for the first time. While she isn’t developing software, her CIS minor and a tendency to tinker with AI tools to streamline her own work keep her up to speed on the team’s work. She co-organizes and hosts the Louisville AI Exchange, and she can’t rest until all her work is done.
Expert: Doug Compton
Born and raised in Louisville, Doug’s interest in technology started at 11 when he began writing computer games. What began as a hobby turned into his career. With broad interests that range anywhere from snorkeling, science, WWII history and real estate, Doug uses his “down time“ to create new technologies for mobile and web applications.
Expert: Steve Anderson
Steve is one of our AWS certified solutions architects. Whether it’s coding, testing, deployment, support, infrastructure, or server set-up, he’s always thinking about the cloud as he builds. Steve is extremely adaptable, and can pick up the project and run with it. He’s flexible and able to fill in where needed. In his spare time, he enjoys family time, the outdoors and reading.
Frequently Asked Questions
AI lowered the effort required to attack a system, which changed the math that used to keep smaller companies off the target list. Writing custom tooling for a specific application once took weeks of skilled manual work, so low-value targets were rarely worth pursuing. With AI, an attacker can prompt their way through that work and run attempts across multiple sites at once. The company's value did not increase. The cost of attacking it collapsed.
A supply chain attack happens when an attacker plants an exploit inside a third-party library, package, or container image that other companies depend on. Teams pull in the compromised code during a routine update, so the vulnerability enters through a trusted dependency rather than their own codebase. Common entry points include npm packages that run binaries during installation and malicious Docker images used in CI builds, which can reach production and enable data exfiltration.
A practical rule of thumb is three days to a week. Letting a new release sit gives the community time to discover and announce anything nefarious before it reaches your build. That cooldown pairs with an equally important habit: keep upgrading. Modern frameworks are far faster to update than they used to be, so the patch work that was once hard to justify now gets approved and turns around quickly.
Start with libraries that have large user bases and active review communities, since more eyes make it harder for malicious code to slip through. Watch for the blind spot: download counts measure popularity, not oversight, and a widely used package can still depend on one volunteer reviewing pull requests at night. For business-critical dependencies, run full code reviews where source is available and maintain a database of which packages have been reviewed and cleared. Treat vetting as ongoing, because a clean scan only means nothing has been reported yet.
Yes, and that capability is most valuable against multi-chained exploits where three or four separate weaknesses combine across files. Those chains are difficult for a human reviewer to hold in memory, but AI assembles the pieces quickly. Add an automated AI code review to the deployment pipeline ahead of human review, and run a scheduled security audit of existing code rather than waiting for someone to find time. It supplements human review instead of replacing it, and it points the same analysis attackers use back at your own codebase first.
