3 ms·

There are always signs, and they are easy to rationalise in hind-sight. The danger is that there are signs for lots of things, so jumping to conclusions regard

There are always signs, and they are easy to rationalise in hind-sight. The danger is that there are signs for lots of things, so jumping to conclusions regarding the reason can be dangerous. For example, we recently got a contract with a company fanatical about security. They wanted additional special insurances, which in turn wanted additional company-wide security policies. This affected everyone, even though the potential contract only affected 3 employees. (And there was an NDA regarding the possibility of a deal.) The policy changes (despite being good policy anyway) likely caused some anguish. So by all means speculate away, staff love a good rumor, and in the absence of information will speculate anything and everything. But I caution against making big life choices based on that speculation.

bruce343434 3y ago
That security point stood out to me as well. First of all, who intentionally writes code to contain SQL injection vulnerabilities anno 2024? Or knows about it and doesn't fix it? Is it really that weird that someone fixes it?
- pflenker 3y ago
  The SQL example relates to an acquisition that happened in 2013, and states that the vulnerabilities have been around for some time. The early 2010s have really been a different time in that regard.
- lozenge 3y ago
  Sometimes there's clearly no risk but an automated tool flags it anyway? Requiring a creative and meaningless "fix".
  - danudey 3y ago
    Our product undergoes CVE scans before every release, and we ensure that all relevant CVEs are handled before we release; if a CVE is low-severity and isn't relevant to our use of the component (e.g. an information disclosure vulnerability in SASL authentication, but we don't use the library for authentication) then we make a note of that for our customers so they know that, while this CVE does exist and may show up in their own scans, it's not relevant to their use of our product. That said, we now have some customers who have extremely stringent security requirements, and for understandable reasons. They want every CVE resolved for every release; this is going to cause a notable amount of work to 'resolve' issues which aren't issues by taking developer time to update and test third-party libraries, or even patch the libraries ourselves if the upstream CVE hasn't been resolved yet. It's unquestionably worth doing if this is a dealbreaker for our customers, but could definitely impact things in the short term by requiring fixes which are technically unnecessary.
- shoo 3y ago
  > First of all, who intentionally writes code to contain SQL injection vulnerabilities anno 2024? here's some ways it could happen: - startup doesn't have ability to hire competent, experienced developers. they end up with rookies with potential but not enough experience to avoid security foot-guns, and/or experienced expert-beginner developers who have a low level of ability - leadership doesn't value quality or security, so the company culture reflects this and focuses on what leadership values - startup outsources development work and has no in-house technical capability to check quality or security of deliverables - startup is pre product-market fit in a domain where security is less relevant, and security issues are less of a risk to the business than the more existential concern around identifying and de-risking a scalable, profitable business model. then suddenly the throwaway proof of concept codebase for the 7th pivot starts getting traction, and by shovelling features on top it is possible to win more customers
bjackman 3y ago
It seems unwise to make life choices based on even the sure fact that your employer is in acquisition talks? Probably even if you are a founder personally carrying out acquisition talks? I guess the exception might be the decision to wait a couple of months before making some other decision!
deleted 3y ago
[deleted]

bruce343434 3y ago

That security point stood out to me as well. First of all, who intentionally writes code to contain SQL injection vulnerabilities anno 2024? Or knows about it and doesn't fix it? Is it really that weird that someone fixes it?

pflenker 3y ago
The SQL example relates to an acquisition that happened in 2013, and states that the vulnerabilities have been around for some time. The early 2010s have really been a different time in that regard.
lozenge 3y ago
Sometimes there's clearly no risk but an automated tool flags it anyway? Requiring a creative and meaningless "fix".
- danudey 3y ago
  Our product undergoes CVE scans before every release, and we ensure that all relevant CVEs are handled before we release; if a CVE is low-severity and isn't relevant to our use of the component (e.g. an information disclosure vulnerability in SASL authentication, but we don't use the library for authentication) then we make a note of that for our customers so they know that, while this CVE does exist and may show up in their own scans, it's not relevant to their use of our product. That said, we now have some customers who have extremely stringent security requirements, and for understandable reasons. They want every CVE resolved for every release; this is going to cause a notable amount of work to 'resolve' issues which aren't issues by taking developer time to update and test third-party libraries, or even patch the libraries ourselves if the upstream CVE hasn't been resolved yet. It's unquestionably worth doing if this is a dealbreaker for our customers, but could definitely impact things in the short term by requiring fixes which are technically unnecessary.
shoo 3y ago
> First of all, who intentionally writes code to contain SQL injection vulnerabilities anno 2024? here's some ways it could happen: - startup doesn't have ability to hire competent, experienced developers. they end up with rookies with potential but not enough experience to avoid security foot-guns, and/or experienced expert-beginner developers who have a low level of ability - leadership doesn't value quality or security, so the company culture reflects this and focuses on what leadership values - startup outsources development work and has no in-house technical capability to check quality or security of deliverables - startup is pre product-market fit in a domain where security is less relevant, and security issues are less of a risk to the business than the more existential concern around identifying and de-risking a scalable, profitable business model. then suddenly the throwaway proof of concept codebase for the 7th pivot starts getting traction, and by shovelling features on top it is possible to win more customers

bjackman 3y ago

It seems unwise to make life choices based on even the sure fact that your employer is in acquisition talks? Probably even if you are a founder personally carrying out acquisition talks? I guess the exception might be the decision to wait a couple of months before making some other decision!

deleted 3y ago

[deleted]