6 ms·

Working in the EU energy sector where we have to work with NIS2 compliance, I'd argue that your security team rightly pointed it out. I suspect that's what you

Working in the EU energy sector where we have to work with NIS2 compliance, I'd argue that your security team rightly pointed it out. I suspect that's what you mean though, and the rightly is just there because you agree with it but don't like it. We work with even more tight dependencies policies than just having alerts. We have a set of pre-approved and yearly vetted packages, like pandas or pyarrow for Python data work. Aside from that we have some isolated development environments where your pipeline can get access to something like SQLC for Go. Which is essentially where your dev dependency lives in it's own environment where it can produce the code it needs to and then submit it for approval into your regular dev environment. 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.

jamesfinlayson 3mo ago
Yeah I completely understand their intent, but I might get 30 vulnerabilities across a multiple repos flagged in a week. It is already tedious to check them all and assess if they're worth worrying about let alone having to update them. These are 99% Javascript though - I suspect other ecosystems are much more manageable.
- Gigachad 3mo ago
  It's easier to keep stuff up to date these days. If you have a project with typescript, unit tests, and end to end tests like cypress you can just have dependabot create the PRs to update packages. If everything passes you just have to hit the merge button. Just updating everything is probably easier than assessing if it's possible to trigger an exploit with the way you use the package.
  - froddd 3mo ago
    This is exactly how developers of malware want you to behave. Update without really thinking about it. 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.
    - KptMarchewa 3mo ago
      Dependency cooldowns fix most of those problems.
    - capitol_ 3mo ago
      The cooldown setting in dependabot solves this attack vector. By setting it you give security vendors time to scan new packages.
      - clates 3mo ago
        Notably this does nothing to "solve" the attack vector. You've got a live bomb in front of you and you're adding 10s to the countdown hoping that _others_* find it and defuse it in that time period. 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?
        fragmede 3mo ago
        With today's AI glut of tokens, multiple someones are scanning security checks against the changed code. The real problem, as was before, was getting anybody anywhere to pay enough attention for long enough.
      - bluGill 3mo ago
- varjag 3mo ago
  I unironically think the solution is vibecoding your own Javascript blobs that use no frameworks and have no (or minimal) external dependencies. At this point it is entirely feasible for many kinds of projects.
  - LtWorf 3mo ago
    Sure, so you'll be vulnerable to all sort of things because vibe code is really insecure (as I've personally seen).
throwaway2037 3mo ago
First, this is great reply with lots of real world experience to share. > I do think external dependencies are among our biggest security threats though. This sounds like a good business opportunity. I know that Sonatype has a business to vet Java dependencies. Does your company use it? I am guessing that Sonatype may be expanding into other open source ecosystems.
- sam_lowry_ 3mo ago
  > First, this is great reply with lots of real world experience to share. 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.
  - lixtra 3mo ago
    Of course, all the generated code has to reviewed and vetted for by a senior developer. Of course, this has to be re-done every now and then when new classes of vulnerabilities appear that the previous generation didn’t have in mind. Or do you just trust the AI that was trained on a lot of bogus code?
    - LtWorf 3mo ago
      The latter, of course.
- Quothling 3mo ago
  Companies like Sonatype would be an issue since they are owned by USA private equity. We would not give "Vista Equity" access to anything with the current EU US relationship. It's bad enough that we're so tied into Microsoft, which the EU might task us with leaving if they deem it critical enough for the security of the European energy sector. That's a risk we live with though, there isn't a realistic alternative. 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.
TeMPOraL 3mo ago
> compliance basically comes down to "We trust the [third party] enough, and [third party component] is vital to our business, so we accept the risks" 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").
- gautamsomani 3mo ago
  Asking out of curiousity - how would you or how does your org handles this right now?
  - robertlagrant 3mo ago
    I'm not the previous poster, but in my experience you can get a lot of mileage out of having dev teams (tediously, at least the first time) go through all potential vulnerabilities, decide how risky each one is based on likelihood and impact, and then get them to address the high/highs somehow (e.g. by upgrading a dependency, or writing extra code to guard against the issue, or fixing the issue if it's a home-grown vulnerability).
- clates 3mo ago
  I've almost always gotten everything I want from security teams over my career. Usually a quick and honest chat with them gets you pretty far. I always lead with some flavor of "In my perfect world, I have 100% access and ability to everything, everywhere all the time. In your perfect world, I don't even have a computer. Here's why I need X permission / Y user group / z application" 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.

jamesfinlayson 3mo ago

Yeah I completely understand their intent, but I might get 30 vulnerabilities across a multiple repos flagged in a week. It is already tedious to check them all and assess if they're worth worrying about let alone having to update them. These are 99% Javascript though - I suspect other ecosystems are much more manageable.

Gigachad 3mo ago
It's easier to keep stuff up to date these days. If you have a project with typescript, unit tests, and end to end tests like cypress you can just have dependabot create the PRs to update packages. If everything passes you just have to hit the merge button. Just updating everything is probably easier than assessing if it's possible to trigger an exploit with the way you use the package.
- froddd 3mo ago
  This is exactly how developers of malware want you to behave. Update without really thinking about it. 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.
  - KptMarchewa 3mo ago
    Dependency cooldowns fix most of those problems.
  - capitol_ 3mo ago
    The cooldown setting in dependabot solves this attack vector. By setting it you give security vendors time to scan new packages.
    - clates 3mo ago
      Notably this does nothing to "solve" the attack vector. You've got a live bomb in front of you and you're adding 10s to the countdown hoping that _others_* find it and defuse it in that time period. 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?
      - fragmede 3mo ago
        With today's AI glut of tokens, multiple someones are scanning security checks against the changed code. The real problem, as was before, was getting anybody anywhere to pay enough attention for long enough.
    - bluGill 3mo ago
varjag 3mo ago
I unironically think the solution is vibecoding your own Javascript blobs that use no frameworks and have no (or minimal) external dependencies. At this point it is entirely feasible for many kinds of projects.
- LtWorf 3mo ago
  Sure, so you'll be vulnerable to all sort of things because vibe code is really insecure (as I've personally seen).

throwaway2037 3mo ago

First, this is great reply with lots of real world experience to share. > I do think external dependencies are among our biggest security threats though. This sounds like a good business opportunity. I know that Sonatype has a business to vet Java dependencies. Does your company use it? I am guessing that Sonatype may be expanding into other open source ecosystems.

sam_lowry_ 3mo ago
> First, this is great reply with lots of real world experience to share. 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.
- lixtra 3mo ago
  Of course, all the generated code has to reviewed and vetted for by a senior developer. Of course, this has to be re-done every now and then when new classes of vulnerabilities appear that the previous generation didn’t have in mind. Or do you just trust the AI that was trained on a lot of bogus code?
  - LtWorf 3mo ago
    The latter, of course.
Quothling 3mo ago
Companies like Sonatype would be an issue since they are owned by USA private equity. We would not give "Vista Equity" access to anything with the current EU US relationship. It's bad enough that we're so tied into Microsoft, which the EU might task us with leaving if they deem it critical enough for the security of the European energy sector. That's a risk we live with though, there isn't a realistic alternative. 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.

TeMPOraL 3mo ago

> compliance basically comes down to "We trust the [third party] enough, and [third party component] is vital to our business, so we accept the risks" 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").

gautamsomani 3mo ago
Asking out of curiousity - how would you or how does your org handles this right now?
- robertlagrant 3mo ago
  I'm not the previous poster, but in my experience you can get a lot of mileage out of having dev teams (tediously, at least the first time) go through all potential vulnerabilities, decide how risky each one is based on likelihood and impact, and then get them to address the high/highs somehow (e.g. by upgrading a dependency, or writing extra code to guard against the issue, or fixing the issue if it's a home-grown vulnerability).
clates 3mo ago
I've almost always gotten everything I want from security teams over my career. Usually a quick and honest chat with them gets you pretty far. I always lead with some flavor of "In my perfect world, I have 100% access and ability to everything, everywhere all the time. In your perfect world, I don't even have a computer. Here's why I need X permission / Y user group / z application" 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.