ievans
Joined 14 years ago
Karma
725
Submissions
91
Member since
Aug 3
Recent submissions
Comment · 2 months ago
It's crazy to me is that the Github API for this is so nascent for something that has such a large attack surface. E.g., even if you pin your actions directly, there's still no equivalent of an action lockfile* so all the transitives are still unpinned.
*(I think Github said this is on the roadmap a few months ago)
Comment · 4 months ago
Last year I thought that AI-generated code would be scanned the same way as human-generated code. What I realized from working on Guardian was that being in the agent loop is an unfair advantage: you can ask the agent to switch to a secure library (eg, defusedxml for python) and it will happily do it before code lands. If you asked a developer to do that in a CI code review, it's a lot more context switching and work.
That means there is an unprecedented opportunity to make both security and developer outcomes better by shaping agent behavior towards secure defaults. Even things like "don't add dependencies unless these conditions are met; we only want top1000 NPM dependencies, otherwise just write it yourself."
Capabilities like this will have a big impact on the OSS ecosystem (positive and negative) as they profilerate.
Comment · 6 months ago
Top comment has a great explicit refutation:
> This plan works by letting software supply chain companies find security issues in new releases. Many security companies have automated scanners for popular and less popular libraries, with manual triggers for those libraries which are not in the top N.
Comment · 8 months ago
Not super surprising that Anthropic is shipping a vulnerability detection feature -- OpenAI announced Aardvark back in October (https://openai.com/index/introducing-aardvark/) and Google announced BigSleep in Nov 2024 (https://cloud.google.com/blog/products/identity-security/clo...).
The impact question is really around scale; a few weeks ago Anthropic claimed 500 "high-severity" vulnerabilities discovered by Opus 4.6 (https://red.anthropic.com/2026/zero-days/). There's been some skepticism about whether they are truly high severity, but it's a much larger number than what BigSleep found (~20) and Aardvark hasn't released public numbers.
As someone who founded a company in the space (Semgrep), I really appreciated that the DARPA AIxCC competition required players using LLMs for vulnerability discovery to disclose $cost/vuln and the confusion matrix of false positives along with it. It's clear that LLMs are super valuable for vulnerability discovery, but without that information it's difficult to know which foundation model is really leading.
What we've found is that giving LLM security agents access to good tools (Semgrep, CodeQL, etc.) makes them significantly better esp. when it comes to false positives. We think the future is more "virtual security engineer" agents using tools with humans acting as the appsec manager. Would be very interested to hear from other people on HN who have been trying this approach!
Comment · 9 months ago
"Staged publishing: A new publication model that gives maintainers a review period before packages go live, with MFA-verified approval from package owners. This empowers teams to catch unintended changes before they reach downstream users—a capability the community has been requesting for years."
Overdue but welcome!
Comment · 1 year ago
This is explicitly not the conclusion Pascal drew with the wager, as described in the next section of the Wikipedia article: "Pascal's intent was not to provide an argument to convince atheists to believe, but (a) to show the fallacy of attempting to use logical reasoning to prove or disprove God..."
Comment · 1 year ago
Do you store your SSDs powered? They can lose information if they're not semi-frequently powered on.
Comment · 1 year ago
For C, you might be interested in https://github.com/weggli-rs/weggli or https://github.com/semgrep/semgrep (I work on the latter). Both are also tree-sitter based.
Comment · 1 year ago
Looks like the `ets` readme has a direct comparison:
> The purpose of ets is similar to that of moreutils ts(1), but ets differentiates itself from similar offerings by running commands directly within ptys, hence solving thorny issues like pipe buffering and commands disabling color and interactive features when detecting a pipe as output. (ets does provide a reading-from-stdin mode if you insist.) ets also recognizes carriage return as a line seperator, so it doesn't choke if your command prints a progress bar. A more detailed comparison of ets and ts can be found below.
Comment · 2 years ago
I wrote up a Semgrep rule as a comparison to add! (also tree-sitter based, `pip install Semgrep`, https://github.com/semgrep/semgrep, or play with live editor link: https://semgrep.dev/playground/s/nJ4rY)
pattern: |-
def $FUNC(..., database, ...):
$...BODY
fix: |-
def $FUNC(..., db, ...):
$...BODYComment · 2 years ago
So the argument is because the vulnerability lifetime is exponentially distributed, focusing on secure defaults like memory safety in new code is disproportionately valuable, both theoretically and now evidentially seen over six years on the Android codebase.
Amazing, I've never seen this argument used to support shift/left secure guardrails but it's great. Especially for those with larger, legacy codebases who might otherwise say "why bother, we're never going to benefit from memory-safety on our 100M lines of C++."
I think it also implies any lightweight vulnerability detection has disproportionate benefit -- even if it was to only look at new code & dependencies vs the backlog.
Contact me at isaac at that domain ^
[ my public key: https://keybase.io/ine; my proof: https://keybase.io/ine/sigs/lLgIx6kHhFdId2nkYud-g18G-usi9L4GzJVXQMjK6qM ]