3 ms·

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 a

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

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