lack of response, SAST developers' unwillingness to accept a flaw as an issue, NDA/confidentiality of product code, and lack of incentives.

6. Security, being a weak-linked software property, can only be holistically improved when SASTs focus on hard-to-find vulnerabilities, focusing more on reducing false negatives instead of inheriting the focus on reducing false positives from the program analysis domain.

7. That can only be done by raising awareness about Flaws in SASTs, aligning the design goals of SASTs with the goals of practitioners, designing evaluation protocol, and streamlining the false-negative reporting process.

8. The full paper, in both PDF and web-readable format, is available here! https://amitsealami.com/false-negatives-kill/

3. Furthermore, while participants described their strong preference towards security, the processes for selecting SASTs did not reflect such a strong preference. We identified two critical reasons based on our findings:

a. Lack of Motivation: practitioners often seemed unreasonably optimistic about SASTs' abilities, assuming that SASTs "just work."

b. Lack of Means: those who wanted to evaluate described the existing means, such as benchmarks, as biased and/or not representative of real, complex vulnerabilities.

4. Further, we report a critical paradox in SAST-related assumptions in practice. Participants expressed that they rely on SASTs to overcome the limitations (gap) of manual analysis and, at the same time, expect that manual analysis will cover the limitations (flaws) of SASTs.

5. Aggravatingly, even if practitioners find flaws, they are hesitant to report those flaws because of the experienced