Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Turn Dependabot off

words.filippo.io

Post reply on HN
Print view View original

131–140 of 195 posts

Re: Turn Dependabot off

#131

Post by maweki »

Chris_Newton wrote: post #113

Dependabot has some value IME, but all naïve tools that only check software and version numbers against a vulnerability database tend to be noisy if they don’t then do something else to determine whether your code is actually exposed to a matching vulnerability. One security checking tool that has genuinely impressed me recently is CodeQL. If you’re using GitHub, you can run this as part of GitHub Advanced Security.…

> it is inherently resistant to false positives

By Rice's Theorem, I somehow doubt that.

Re: Turn Dependabot off

#132

Post by summarity »

silverwind wrote: post #125
Chris_Newton wrote: post #113

Dependabot has some value IME, but all naïve tools that only check software and version numbers against a vulnerability database tend to be noisy if they don’t then do something else to determine whether your code is actually exposed to a matching vulnerability. One security checking tool that has genuinely impressed me recently is CodeQL. If you’re using GitHub, you can run this as part of GitHub Advanced Security.…

CodeQL seems to raise too many false-positives in my experience. And it seems there is no easy way to run it locally, so it's a vendor lock-in situation.

Heyo, I'm the Product Director for detection & remediation engines, including CodeQL.

I would love to hear what kind of local experience you're looking for and where CodeQL isn't working well today.

As a general overview:

The CodeQL CLI is developed as an open-source project and can run CodeQL basically anywhere. The engine is free to use for all open-source projects, and free for all security researchers.

The CLI is available as release downloads, in homebrew, and as part of many deployment frameworks: https://github.com/advanced-security/awesome-codeql?tab=read...

Results are stored in standard formats and can be viewed and processed by any SARIF-compatible tool. We provide tools to run CodeQL against thousands of open-source repos for security research.

The repo linked above points to dozens of other useful projects (both from GitHub and the community around CodeQL).

Re: Turn Dependabot off

#133

Post by cedws »

I don’t know why the industry collectively accepted these security scanners (code + containers) that don’t even do the most basic of static analysis to see if the vulnerable code is reachable. Companies are breaking their backs trying to maintain a constant zero vulnerabilities in their container images when 99% of the CVEs don’t actually affect them anyway. The kicker is that updating the dependencies probably just introduces new CVEs to be discovered later down the line because most software does not backport fixes.

Re: Turn Dependabot off

#134

Post by eru »

cedws wrote: post #133

I don’t know why the industry collectively accepted these security scanners (code + containers) that don’t even do the most basic of static analysis to see if the vulnerable code is reachable. Companies are breaking their backs trying to maintain a constant zero vulnerabilities in their container images when 99% of the CVEs don’t actually affect them anyway. The kicker is that updating the dependencies probably just…

> The kicker is that updating the dependencies probably just introduces new CVEs to be discovered later down the line because most software does not backport fixes.

I don't understand how the second part of that sentence is connected to the first.

Re: Turn Dependabot off

#135

Post by eru »

varispeed wrote: post #118
Chris_Newton wrote: post #113

Dependabot has some value IME, but all naïve tools that only check software and version numbers against a vulnerability database tend to be noisy if they don’t then do something else to determine whether your code is actually exposed to a matching vulnerability. One security checking tool that has genuinely impressed me recently is CodeQL. If you’re using GitHub, you can run this as part of GitHub Advanced Security.…

Bumping version of dependencies doesn't guarantee any improved safety as new versions can introduce security issues (otherwise we wouldn't have a need of patching old versions that used to be new).

Maybe. But at least everyone being on the same (new) version makes things simpler, compared to everyone being on different random versions, of what ever used to be current when they were written.

Re: Turn Dependabot off

#136

Post by eru »

jpollock wrote: post #38
staticassertion wrote: post #31

Earlier quoted context omitted.

TBH I Think that DoS needs to stop being considered a vulnerability. It's an availability concern, and availability, despite being a part of CIA, is really more of a principle for security rather than the domain of security. In practice, availability is far better categorized as an operational or engineering concern than a security concern and it does far, far more harm to categorize DoS as a security conern than it…

The severity of the DoS depends on the system being attacked, and how it is configured to behave on failure. If the system is configured to "fail open", and it's something validating access (say anti-fraud), then the DoS becomes a fraud hole and profitable to exploit. Once discovered, this runs away _really_ quickly. Treating DoS as affecting availability converts the issue into a "do I want to spend $X from a shaked…

Also in eg C code, many exploits start out would only be a DoS, but can later be turned into a more dangerous attack.

Re: Turn Dependabot off

#137

Post by eru »

lazyasciiart wrote: post #93
jpollock wrote: post #52

Earlier quoted context omitted.

If the majority of your customers are good, failing closed will cost more than the fraud during the anti-fraud system's downtime.

Until any bad customer learns about the fail-open.

If bad actors learn about the fail-close, they can conceivably cause you more harm.

Re: Turn Dependabot off

#138

Post by summarity »

maweki wrote: post #131
Chris_Newton wrote: post #113

Dependabot has some value IME, but all naïve tools that only check software and version numbers against a vulnerability database tend to be noisy if they don’t then do something else to determine whether your code is actually exposed to a matching vulnerability. One security checking tool that has genuinely impressed me recently is CodeQL. If you’re using GitHub, you can run this as part of GitHub Advanced Security.…

> it is inherently resistant to false positives By Rice's Theorem, I somehow doubt that.

No engine can be 100% perfect of course, the original comment is broadly accurate though. CodeQL builds a full semantic database including types and dataflow from source code, then runs queries against that. QL is fundamentally a logic programming language that is only concerned with the satisfiably of the given constraint.

If dataflow is not provably connected from source to sink, an alert is impossible. If a sanitization step interrupts the flow of potentially tainted data, the alert is similarly discarded.

The end-to-end precision of the detection depends on the queries executed, the models of the libraries used in the code (to e.g., recognize the correct sanitizers), and other parameters. All of this is customizable by users.

All that can be overwhelming though, so we aim to provide sane defaults. On GitHub, you can choose between a "Default" and "Extended" suite. Those are tuned for different levels of potential FN/FP based on the precision of the query and severity of the alert.

Severities are calculated based on the weaknesses the query covers, and the real CVE these have caused in prior disclosed vulnerabilities.

QL-language-focused resources for CodeQL: https://codeql.github.com/

Re: Turn Dependabot off

#139

Post by Chris_Newton »

maweki wrote: post #131
Chris_Newton wrote: post #113

Dependabot has some value IME, but all naïve tools that only check software and version numbers against a vulnerability database tend to be noisy if they don’t then do something else to determine whether your code is actually exposed to a matching vulnerability. One security checking tool that has genuinely impressed me recently is CodeQL. If you’re using GitHub, you can run this as part of GitHub Advanced Security.…

> it is inherently resistant to false positives By Rice's Theorem, I somehow doubt that.

Sorry, I don’t understand the point you’re making. If CodeQL reports that you have a XSS vulnerability in your code, and its report includes the complete and specific code path that creates that vulnerability, how is Rice’s theorem applicable here? We’re not talking about decidability of some semantic property in the general case; we’re talking about a specific claim about specific code that is demonstrably true.

Re: Turn Dependabot off

#140

Post by Chris_Newton »

silverwind wrote: post #125
Chris_Newton wrote: post #113

Dependabot has some value IME, but all naïve tools that only check software and version numbers against a vulnerability database tend to be noisy if they don’t then do something else to determine whether your code is actually exposed to a matching vulnerability. One security checking tool that has genuinely impressed me recently is CodeQL. If you’re using GitHub, you can run this as part of GitHub Advanced Security.…

CodeQL seems to raise too many false-positives in my experience. And it seems there is no easy way to run it locally, so it's a vendor lock-in situation.

CodeQL seems to raise too many false-positives in my experience.

I’d be interested in what kinds of false positives you’ve seen it produce. The functionality in CodeQL that I have found useful tends to accompany each reported vulnerability with a specific code path that demonstrates how the vulnerability arises. While we might still decide there is no risk in practice for other reasons, I don’t recall ever seeing it make a claim like this that was incorrect from a technical perspective. Maybe some of the other types of checks it performs are more susceptible to false positives and I just happen not to have run into those so much in the projects I’ve worked on.

Post reply on HN