Mastodawn

Mar 9

Jackie Singh Mar 7

Infosec pros fight ransomware, APTs, and foreign disinfo for a living. But when Trump weaponizes clearances, hollows out @CISAgov, and unleashes @DOGE as a systemic insider threat, our industry mostly chooses self‑preservation.

Join me as I unpack that trap: https://www.hackingbutlegal.com/p/the-industry-that-fights-governments #infosec

Most security reports could be a couple sentences and a small code snippet, and would be better for it. I hate that every report is written as if it were a blog post about their finding and how it's the greatest disaster of all time. Write as if you're having a dialog with a knowledgeable maintainer, wait for questions to elaborate if needed. LLMs have not made this better either.

@jacob I hope Gender Dr. has a side street named Miss Pl.

@glyph @jacob The hackerone AI pivot makes sense to me. There is a lot of value in automating so much of that work now that we can. Anyone seeking bounties is already doing the same.

@jacob agreed, they aren't high value for community run open source. Well resourced commercial entities can justify it. The Googles, Apples, and Microsofts have TM bearing Brands and Contractual Obligations to maintain.

Anyone trying to collectively organize bounties for OSS projects (is this what hackerone was doing?) is already on shaky ground if they don't provide expertise based filtering of reports seeking a bounty as part of that so that only actually worthy ones make it through to the volunteers.

At the end of the day, a security bug bounty program is a way to underpay a tiny fraction of gig-workers competing for work. In direct financial competition with their alt-gig-reward system of zero day exploit markets and state sponsored equivalent employers.

@nedbat Soo much test flakiness due to lru_cache decorators being added to codebases over time. Much hunting down caches and plumbing clears into fixtures ensues. I think in hindsight offering functools.lru_cache as a decorator was a bit too magical of a code pattern. I'd like anything cached to require a _cached suffix on its name. But that only solves highlighting immediate use of APIs where the name is seen. Most code involves transitive calls.

Use of a cache is effectively a taint that'd be nice to propagate upwards - it sounds like `pytest-antilru` effectively attempts this?! nice! - so that any given API use could be introspected to understand what caches code touched and how to clear them.

Runtime tracking such as the above is neat and practical. But from a static analysis PoV. It's "just" metadata on the data flow graph. I wonder what other design mistakes could be prevented via analysis if that were readily available without running the code.