Lmst

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

While we have been focusing on reducing false positives in vulnerability detection, my IEEE S&P'24 paper, in collaboration with Kevin Moran, Denys Poshyvanyk, and Adwait Nadkarni, shows the contrary: developers would rather have more false positives if the tool finds the vulnerabilities. FNs are of more concern to them. Key insights below:

1. While we found several insights that match existing literature, e.g., "Select situations can lead to the de-prioritization of software security," the rest challenge existing literature, identifying challenges that need attention from practitioners, SAST developers, and researchers.

2. For example, "Developer Happiness is Key" is the primary design goal of program analysis tools, thus focusing on reducing false positives in general. However, participants strongly favor reducing false negatives because "that one is going to kill you".

Further Key insights and the full paper are available below:

tags: #IEEESSP'24 #sp #security #sast #study #stem #WM

Amit Seal Ami boosted:

Great scoop by @kimzetter: DoJ, Mandiant and Microsoft stumbled upon the SolarWinds breach six months earlier than previously reported, but were unaware of the significance of what they had found.

Amazing this is only surfacing publicly now.

https://www.wired.com/story/solarwinds-hack-public-disclosure/

Happy new year. :ablobcatattention:

Last year I did not do much. I hope I will do more this year.

Regardless, I pray that everyone around me will live happily, with sound health and with peace.

I pray the same for you. 🙏

#newyear #newyear2023

@natedog nice! 😆

Read this question earlier: "Can you name a famous horse without googling?"

---

me instantly: TROJAN HORSE 🙋‍♂️
also me: But.. that's not an actual horse 🤦‍♂️
then me: Still a horse! 🤷‍♂️

I sure hope I am not the only one who went through this route of thinking.

Nothing against the individual in this filter, to be honest. But I was being bombarded with news and articles about him in my news feed, here, and elsewhere. I am glad if you want to discuss about things he has been doing, but I am not really interested to know about this person any more.

This is a lifesaver in Mastodon!

Instant sanitization of my mastodon feed. 🙏🏼

Sharing this in case someone else needs it.