6 ms·

Your vision is only workable for software for which there are no security concerns. This might improve to the extent industry slowly moves away from utterly ir

by patrec 8y ago

Your vision is only workable for software for which there are no security concerns. This might improve to the extent industry slowly moves away from utterly irresponsible technologies like memory-unsafe languages and brain damaged parsing and templating approaches and more or less the whole web stack. I wouldn't hold my breath though. And even software that's not cavalierly insecure will have security flaws, albeit at a lower rate.

dalf 8y ago
What if the new node version fix an bug / issue / CVE that doesn't concern the software ? Is it resonable to postpone the upgrade for later ? Example : the software uses python requests. A new version fixes CVE-2018-18074 about Authorization header, but you don't use this header, for sure. Is it resonable to upgrade a little bit later ?
- viraptor 8y ago
  Depends on how mature is your security team/process. Can you spend time tracking separate announced bugs and make case by case decision for each cve? How much would you trust that review? Do you review dependencies which may trigger the same issue? Or is it going to take less time/effort to upgrade each time? Or is the code so trivial you can immediately make the decision to skip that patch? There's no perfect answer - you have to decide what's reasonable for your teams.
- nerdbeere 8y ago
  The cool thing about serverless infrastructure is that it does not really concern you. As long as you are on a maintained version of the underlying platform your provider will take care of the updates. If your software runs on a unmaintained platform there won't be any security fixes and that's why amazon forces you to upgrade at some point.
  - ldoughty 8y ago
    AWS, at least, didn't make any promises for updates for serverless Lambda that I can see in their docs.
    - nerdbeere 8y ago
      Right, because it's not relevant to you. You don't care about the underlying infrastructure in terms of security, amazon does that for you.
jasonkester 8y ago
Keep in mind that you're arguing against an existence disproof. The Microsoft stack, for example, is a pretty big target for attack, and has seen its share of security issues over the years. But developers don't need to make any code changes or redeploy anything to mitigate those security issues. It all happens through patches on the server, 99% of which happen automatically via windows update.
- lmm 8y ago
  > Keep in mind that you're arguing against an existence disproof. The Microsoft stack, for example, is a pretty big target for attack, and has seen its share of security issues over the years. > But developers don't need to make any code changes or redeploy anything to mitigate those security issues. I don't believe it. Most security issues are not just an implementation issue in the framework but an API that is fundamentally insecure and cannot be used safely. Most likely those developers' programs are rife with security issues that will never be fixed.
  - AnIdiotOnTheNet 8y ago
    Which is fine, as long as they are understood and mitigated against. If your security policy consists entirely of "keep software up to date", you don't have a security policy.
    - lmm 8y ago
      In practice trying to "understand and mitigate against" vulnerabilities inherent in older APIs is likely to be more costly and less effective than keeping software up to date.
      - AnIdiotOnTheNet 8y ago
        In practice you don't mitigate against specific vulnerabilities at all, you mitigate against the very concept of a vulnerability. It would be foolish to assume that any given piece of software is free from vulnerabilities just because it is up to date, so you ask yourself "what if this is compromised?" and work from the premise that it can and will be.

by patrec 8y ago

dalf 8y ago

What if the new node version fix an bug / issue / CVE that doesn't concern the software ? Is it resonable to postpone the upgrade for later ? Example : the software uses python requests. A new version fixes CVE-2018-18074 about Authorization header, but you don't use this header, for sure. Is it resonable to upgrade a little bit later ?

viraptor 8y ago
Depends on how mature is your security team/process. Can you spend time tracking separate announced bugs and make case by case decision for each cve? How much would you trust that review? Do you review dependencies which may trigger the same issue? Or is it going to take less time/effort to upgrade each time? Or is the code so trivial you can immediately make the decision to skip that patch? There's no perfect answer - you have to decide what's reasonable for your teams.
nerdbeere 8y ago
The cool thing about serverless infrastructure is that it does not really concern you. As long as you are on a maintained version of the underlying platform your provider will take care of the updates. If your software runs on a unmaintained platform there won't be any security fixes and that's why amazon forces you to upgrade at some point.
- ldoughty 8y ago
  AWS, at least, didn't make any promises for updates for serverless Lambda that I can see in their docs.
  - nerdbeere 8y ago
    Right, because it's not relevant to you. You don't care about the underlying infrastructure in terms of security, amazon does that for you.

jasonkester 8y ago

Keep in mind that you're arguing against an existence disproof. The Microsoft stack, for example, is a pretty big target for attack, and has seen its share of security issues over the years. But developers don't need to make any code changes or redeploy anything to mitigate those security issues. It all happens through patches on the server, 99% of which happen automatically via windows update.

lmm 8y ago
> Keep in mind that you're arguing against an existence disproof. The Microsoft stack, for example, is a pretty big target for attack, and has seen its share of security issues over the years. > But developers don't need to make any code changes or redeploy anything to mitigate those security issues. I don't believe it. Most security issues are not just an implementation issue in the framework but an API that is fundamentally insecure and cannot be used safely. Most likely those developers' programs are rife with security issues that will never be fixed.
- AnIdiotOnTheNet 8y ago
  Which is fine, as long as they are understood and mitigated against. If your security policy consists entirely of "keep software up to date", you don't have a security policy.
  - lmm 8y ago
    In practice trying to "understand and mitigate against" vulnerabilities inherent in older APIs is likely to be more costly and less effective than keeping software up to date.
    - AnIdiotOnTheNet 8y ago
      In practice you don't mitigate against specific vulnerabilities at all, you mitigate against the very concept of a vulnerability. It would be foolish to assume that any given piece of software is free from vulnerabilities just because it is up to date, so you ask yourself "what if this is compromised?" and work from the premise that it can and will be.