> I do think external dependencies are among our biggest security threats though.
I know how they came about with this setup, but I think that's the wrong way of approaching the problem.
Their problem is legacy and trickle-in features in an otherwise unmaintainable code.
With AI, they can rewrite their software to minimize dependencies and in general reduce the attack surface by allowing the business to automate more on their own.
But it requires bold management decisions and people in position of authority that can pick the right battles for the advancement of their careers.
Or do you just trust the AI that was trained on a lot of bogus code?
That being said, our current strategy is more along the lines of building thind within standard libraries. We really wanted to adopt Go company wide, but it's proven impossible for non-SWE staff to use AI to create their projects in anything but Python. So instead we've created AI configurations that know our security policies, the tools we want them to use and we've setup security policies which won't even allow you to run a Python executionable inside a virtual environment unless your devices is sepcifically allowed to do so in that specific folder. Similarily we've completely limited what VSCode extensions they can use down to the named folder version. Which sort of sucks, and I doubt a lot of it would be possible if it wasn't because the c-levels are personally liable for security under EU law.
We'll see what happens after september when the summer holidays are over and the real token cost of AI will kick in.
Just updating everything is probably easier than assessing if it's possible to trigger an exploit with the way you use the package.
I do wonder how long it will take before an attack is developed by submitting a semi-genuine vulnerability, shortly followed by a ‘fix’ including malicious code.
I would challenge anyone proposing this to define more than one party doing security checks on packages to prove the point that many projects are waving their hands nebulously around saying "security vendors" and then YOLO'ing code into their codebase because they didn't here the muses wailing.
Alternatively from the other direction - Point to any dependency in your project. How can you get *POSITIVE SIGNAL* that security vendors _did_ look at it and okay it? How much scrutiny did they put into it? At what version did they last inspect it?
The other option is to simply ignore updates and do them on a schedule, e.g. once every 1-2 months.
Dependencies and supply chain attacks are probably the greatest risk to a lot of software orgs, as they run them across all their environments: Development (with secrets and other valuable artefacts on developer VMs), CI/CD pipelines which may have access tokens to production (and other) environments, and production itself.
Notably even security companies are being impacted by this[0]. The scale of these attacks has amplified quite significantly the past three years, but are not solely exclusive to the javascript ecosystem [1] or even just namesquatting/typosquatting [2].
The resolution is broader security awareness, "onion layered" security controls and implementing simple non-burden inducing processes and policies. Sometimes not updating (what was wrong with the previous version of a dependency if there was no immediate vulnerability or production issue caused by it?) or having a two week cool down for updates (which some supply chain tooling natively supports) can appease some security functions through clear communication of the supply chain risk etc.
If anyone has interest in courses aligned to your org on improving developer and broader engineering management awareness on this, e-mails in my profile :).
[0] - https://socket.dev/blog/ongoing-supply-chain-attack-targets-...
[1] - https://orca.security/resources/blog/hades-pypi-supply-chain...
[2] - https://checkmarx.com/zero-post/python-pypi-supply-chain-att...
This is the beginning and end of reasonable security. This is what it's always about, and if you go beyond it, you risk practicing art for the sake of art, at the expense of customers and other stakeholders.
Security is about understanding and managing risk. Not about achieving some mathematical perfection (which is actually only achievable by making your system an inert piece of rock, but people realize that way too late, after piling on way too many pointless "security improvements").
From the perspective of big corporate security - developers are a wild nuisance who file the lions share of the tickets and soak up an inordinate amount of resources. Being able to at least explain to them that you understand their objectives and are not overrequesting just for the sake of overrequesting goes a long way.
Ironically we'd probably need to run Dependabot itself in a mirrored environment since it too has external dependencies we'd probably not want to vet.
I do think external dependencies are among our biggest security threats though. It's so hard to vet them, and compliance basically comes down to "We trust the apache software foundation enough, and pyarrow is vital to our business, so we accept the risks", and then you lock versions and aren't the first to update except for vulnerabilities. Shadow AI is obviously the number one security threat right now, especially in enterprise with people who are very tech savvy. This makes dependencies so much worse though, because now everyone can (if their systems aren't locked down tight) do so many crazy things. Both with the "non-sanctioned" AI but also with the code it can generate for them.