3 ms·

Its supposed to be part of a larger process, a culture of constantly committing small changes and have many automated gates before you reach production (not jus

by jzoch 7y ago

Its supposed to be part of a larger process, a culture of constantly committing small changes and have many automated gates before you reach production (not just your CI instance). Real CI/CD. Heroku does something like this because they release to a staging instance, gather metrics, rollback if necessary, then release to a canary in production, repeat monitoring, then release to a wider and wider surface area. Obviously this does not fix security bugs introduced, but functionality wise it works well. Security tends to get better over time not worse too when it comes to dependencies i find.

capableweb 7y ago
Sure, I have no problem with having a automated process, but things like reviewing dependencies have to be manual when code has changed, how can you otherwise ensure there is nothing nasty hidden there? With the dawn of these automated services, it becomes easier to do what you can essentially call propagation-hacks, where one compromised module would trigger bunch of other packages to auto-update, which triggers more and which eventually gets run in your production environment. Also, not sure "security tends to get better over time". When a library is small and unused, no one really cares about reviewing the security as either it's not used by many to warrant it, or it's surface is so small it's not worth for people to try to find holes. As the software grows, it gets more users, and more reviews, which also finds more issues. Probably the security is the same as in the beginning, and depends more on the maintainers, then depending how long it existed. One example could be OpenSSL which everyone been assuming for a long time was totally fine.
- londt8 7y ago
  I think reviewing all code in the dependencies is not reasonable. When i add new dependency to my projects i evaluate how trustworthy the maintainers seem.
  - capableweb 7y ago
    Instead of throwing your hands in the air and saying "Well, too many dependencies, can't review it", you can pull in less dependencies so you can manage to review it. Especially from sources where anyone can publish anything basically.
    - lowdose 7y ago
      Don't use npm?
      - capableweb 7y ago
        Not sure if this is a statement or question. Assuming it's a question: Me and my team uses npm, but we're careful about what we pull in. If the dependency has too many dependencies themselves, we either find a alternative, fork it to remove bunch of stuff we don't care about or write something ourselves.

by jzoch 7y ago

capableweb 7y ago

Sure, I have no problem with having a automated process, but things like reviewing dependencies have to be manual when code has changed, how can you otherwise ensure there is nothing nasty hidden there? With the dawn of these automated services, it becomes easier to do what you can essentially call propagation-hacks, where one compromised module would trigger bunch of other packages to auto-update, which triggers more and which eventually gets run in your production environment. Also, not sure "security tends to get better over time". When a library is small and unused, no one really cares about reviewing the security as either it's not used by many to warrant it, or it's surface is so small it's not worth for people to try to find holes. As the software grows, it gets more users, and more reviews, which also finds more issues. Probably the security is the same as in the beginning, and depends more on the maintainers, then depending how long it existed. One example could be OpenSSL which everyone been assuming for a long time was totally fine.

londt8 7y ago
I think reviewing all code in the dependencies is not reasonable. When i add new dependency to my projects i evaluate how trustworthy the maintainers seem.
- capableweb 7y ago
  Instead of throwing your hands in the air and saying "Well, too many dependencies, can't review it", you can pull in less dependencies so you can manage to review it. Especially from sources where anyone can publish anything basically.
  - lowdose 7y ago
    Don't use npm?
    - capableweb 7y ago
      Not sure if this is a statement or question. Assuming it's a question: Me and my team uses npm, but we're careful about what we pull in. If the dependency has too many dependencies themselves, we either find a alternative, fork it to remove bunch of stuff we don't care about or write something ourselves.