Hacker News Reader

Comment by scinerio | Hacker News Reader

Will this ever be integrated with Gitlab Ultimate?

Gitlab Ultimate uses Rezilion to accomplish a similar aim. Rather than using the principle of "reachability", Rezilion analyzes at runtime what functions and classes are loaded to memory. Much more deterministic and less of a guess about what code will be called.

https://about.gitlab.com/blog/2022/03/23/gitlab-rezilion-int...

How does it do that in the face of lazy loading, or for languages in which "what functions and classes are loaded in to memory" is not really a thing (e.g. C)?

Shouldn't this be very easy in C? With static linking, you're vulnerable if you're linking the package. With dynamic linking, you're vulnerable if you're importing the specific functions. Otherwise, you're not vulnerable - there's no other legal way to call a function in C.

Now, if you're memory mapping some file and jumping into it to call that function, good luck. You're already well into undefined behavior territory.

Now, for lazy loading, I'm assuming the answer is the same as any other runtime path analysis tool: it's up to you to make sure all relevant code paths are actually running during the analysis. Presumably your tests should be written in such a way as to trigger the loading of all dependencies.

I think there's really no other reasonable way to handle this, though I can't say I've worked with either GutHub Ultimate or Rezilion, so maybe I'm missing something.

Hey, I work on OP's product, and just wanted to mention that reachability is not always about a function being called. Sometimes insecure behavior is triggered by setting options to a certain value[0]. Other times it's feasible to mark usages of an insecure function as safe when we know that the passed argument comes from a trusted source[1]. The Semgrep rules we write understand these nuances instead of just flagging function calls.

[0]: e.g. https://nvd.nist.gov/vuln/detail/CVE-2021-28957

[1]: e.g. https://nvd.nist.gov/vuln/detail/CVE-2014-0081

Rezilion works at runtime when the Gitlab runner spins up a container for testing the app. Rezilion observes the contents of memory and can reverse-engineer back to the filesystem to see where everything was loaded from.

In the CI pipeline this depends on your tests exercising the app, but when you deploy Rezilion into a longer-lived environment like Stage or Prod then you may get some new code pathways that are used, although most find that the results aren't surprisingly different between all of the environments.

Ah, thank you. It's not entirely clear whether this is something baked into Gitlab Ultimates SAST CI/CD feature/template, or if it's a third party that I would have to license first. Do you happen to know?

Reply on news.ycombinator.com