Introducing Immutable Scans

Application performance is critical for productivity. We’ve all felt the drag when a UI takes longer than expected to respond, and your attention starts to drift. A snappy UI is the difference between staying in the flow and “better go get some coffee.

There’s often a tradeoff though – sometimes you want data to be as fresh as possible, even if it takes a little longer to process. This is the classic dilemma behind the CAP theorem in databases as well as the first of the two famous “hard things” in computer science (cache invalidation).

At Socket, a lot of what we do is scanning your dependency data – your package.json files, lockfiles, and SBOMs. And sometimes you want that data to be as fresh as possible: for example, when something like React2Shell or Shai-Hulud hits, and you’re trying to determine if you’re affected based on the latest research. However, a lot of the time, security teams don't necessarily need the freshest answer – you’re dealing with the day-to-day of well-known vulnerabilities and code quality issues. In that case, it’s painful to wait for a fresh scan.

Furthermore, freshness is not always as important as immutability. Sometimes you want to share the URL of a scan with your team, and then be sure that your teammates will see the same thing when they click five days later. If the URL changes under you, providing fresh data every time you load it, then that’s not only slow but could also cause communication or reproducibility problems.

As Socket has expanded the depth and breadth of its scanning capabilities, we’ve focused on making sure the experience stays fast and predictable. In practice, that means optimizing for speed by default, while still making it easy to get fresh results when it matters most, such as during fast-moving incidents like Shai-Hulud.

How Immutable Scans Work#

In the Socket dashboard, we’ve now gone all-in on the concept of “immutable” scans. When you view a scan or diff scan page, you will see the same results no matter how many times you load the page. And once the scan is finished, the page will load much faster than before. Here’s how it works:

1. The first time you load a scan or diff scan page, a server-side worker will start the scanning process. A progress indicator is shown until the scan has completed.
2. Once complete, scan results are stored and remain accessible: up to 30 days on the free tier and up to one year for paid customers.
3. When you refresh the page, you will now get exactly the results you got on the first scan, every time.
4. If you’d like to get fresher results, you can click the “…” menu in the upper-right corner to trigger a rescan. This rescan will give you a new URL with its own immutability guarantees, based on the same input SBOM data from the original scan.

Rescans#

For regular (non-diff) scans, we offer two types of rescans: shallow and deep.

Shallow rescans are useful for when you just want to verify that your policy changes (e.g. security policy, license policy, or repository labels) are working correctly. These rescans should finish very quickly, because they merely apply your current policies to the cached scan.

Deep rescans are effectively the same as re-running a scan from scratch. They both apply policy changes and recompute the scan output from scratch. This is useful for scan data that may take a long time to compute, such as reachability data (which may require background computation, e.g. for precomputed reachability), or when the underlying research has changed (e.g. newly-discovered CVEs or malware since the scan was taken).

For diff scans, shallow rescans are currently not supported; every scan is effectively a deep rescan.

In the Socket API#

The Socket API also supports immutable scans, although unlike the UI, the behavior is opt-in. We did this to avoid breaking existing use cases that may be relying on the historical “always fresh” behavior.

To use immutable scans, you can use these two endpoints:

• /full-scans/get
• /diff-scans/get

In both cases, you can pass the cached=true parameter to get the immutable behavior. A 202 “Accepted” HTTP response will be sent if the scan is still in progress, or else a normal 200 when the cached scan is available.

Faster, More Reliable Scans#

We’re excited to roll out Immutable Scans and the speed improvements they bring. In practice, this means heavyweight scan pages that once took a long time to load now open in just a few seconds. Customers have also told us they value the confidence of sharing a scan link that stays consistent over time.

As always, we welcome feedback on the new experience. And let us know what you’re doing instead of taking a coffee break.