Why software 'security debt' is becoming a serious problem for developers

Comments

• ArmoredThirteen@lemmy.ml ⁨8⁩ ⁨months⁩ ago

  I worked for the state once and the number of times I had to put my foot down for security was appalling. We’re talking like getting web services updated to use basic password auth could take months and I’d be pressured by management to ignore it because some asshat using the service doesn’t want to update their 30 year old batch file to deal with auth. Other people would regularly push things that could easily expose thousands of people’s identifying info just to get management off their backs. A couple projects I think I was specifically kept away from because they were “mission critical” and they didn’t want me slowing it down with trivial stuff like not leaking unencrypted databases…

  source

  • BrianTheeBiscuiteer@lemmy.world ⁨8⁩ ⁨months⁩ ago

    Very stark contrast to a typical day at my job.

    “Looks like there’s a broken link on this page. No problem, we can get that fixed up in a day or two after we tackle the 32 vulnerabilities that cropped up since the last time we changed that page."

    source
  • jadero@programming.dev ⁨8⁩ ⁨months⁩ ago

    That is something I just don’t get. I’m a hobbyist turned pro turned hobbyist. The only people who I ever offered my services to were either after one of my very narrow specialties where I was actually an expert or literally could not afford a “real” programmer.

    I never found proper security to have any impact on my productivity. Even going back to my peak years in the first decade of this century, there was so much easily accessible information, so many good tutorials, and so many good products that even my prototypes incorporated the basics:

    • Encrypt the data at rest
    • Encrypt the data in transit
    • No shared accounts at any level of access
    • Full logging of access and activity.
    • Before rollout, back up and recovery procedures had to be demonstrated effective and fully documented.

    source

    • CodeMonkey@programming.dev ⁨8⁩ ⁨months⁩ ago

      • Encrypt the data at rest
      • Encrypt the data in transit

      Did you remember to plan for a zero downtime encryption key rotation?

      • No shared accounts at any level of access

      Did you know when account passwords expire? Have you thought about password rotation?

      • Full logging of access and activity.

      That sounds like a good practice until you have 20 (or even 2000) backend server requests per end user operation.

      All of those are taken from my experience.

      Security is like an invasive medical procedure: it is very painful in the short term but prevents dire complications in the long term.

      source

      • -> View More Comments
    • Miaou@jlai.lu ⁨8⁩ ⁨months⁩ ago

      Dependencies, scope creep, feature creep, off by one errors, misconfiguration, unclear/unenforced contracts/invariants… Most of those are trivial to solve at small scale, but the more moving parts you have, the more complex it becomes

      source

      • -> View More Comments
• lightnegative@lemmy.world ⁨8⁩ ⁨months⁩ ago

  Why is it that security guys always think their issues are more important than any other issues?

  Like well done you, you ran an automated tool over the codebase and it picked up some outdated dependencies.

  We cant just update these dependencies because the newer versions have breaking changes and we already have a backlog of 32767 issues to deal with.

  It’s not security debt, it’s just general technical debt.

  Why is the issue that is only exploitable in a contorted scenario where the user has broken out of a VM and gained root on the hypervisor more important than the issue preventing our largest customer from tripling their volume on our platform?

  Not to mention the joke that’s been made of the CVE system due to resume padding by the security industry…

  source

  • Mischala@lemmy.nz ⁨8⁩ ⁨months⁩ ago

    Generally a regular issue is much less likely to get you hacked.
    Security issues often come with legal liability which is why a bad security department will act overly important and stomp around demanding changes be made right the fuck now.

    But I do get it, a good security team should be enabling their dev teams to solve issues in the heat disruptive way possible, not just thrown them work and barking orders.

    In some places I have worked, the sec teans will find an issue and push PRs to fix them, explaining the security concern, and requesting only a review and merge.

    source
  • rostselmasch@lemmygrad.ml ⁨8⁩ ⁨months⁩ ago

    It’s not security debt, it’s just general technical debt.

    I would also say, that this is just technical debt. I also fully understand, that there are things like breaking changes. I remember clearly when we used asyncore in the past for Python at work and then it became deprecated. It was still possible to use it for a long time, but a change was needed. Such breaking changes caused work and are not nice. Especially if it is a big software.

    On the other side, I am not happy if I buy software or hardware, which has probably insecure dependencies. I understand the developers, I am also one, and I know that many things are not under their control. I am also not blaming them. But it is a no-go if something new is sold with 10-year-old OpenSSH Server, 15-year-old curl or other things.

    But I am not taking exotic vulnerabilities that seriously. Like, if you need specific constellations, so this is somehow hackable.

    source