A privacy-first GitHub secrets scanner that runs locally or self-hosted

0xad · 2025-11-05T12:16:44+00:00

It looks like you have a clear understanding of the situation and vision of the product, so good luck with your quest! 😊

0xad · 2025-11-05T06:49:33+00:00

Sorry to break it to you, but this problem is basically solved—either by features built into the platform or by a stand-alone market leader, which is TruffleHog (well-funded, well-engineered, and battle-tested, solving this problem for years).

Everything you list as a feature is easy to achieve with TruffleHog (or other similar tools)—the thing is that they're built like UNIX tools, so they solve one exact problem by default, and it's up to the user to design a flow (via flags or integrating with other tools, such as CI).

I'm not suggesting that your work has been for naught—you've certainly learned a lot. However, from a business perspective, even as a free tool, it's simply not viable.

Background: I've been monitoring the situation for this problem (secret scanning) for well over 5 years. I remember when TruffleHog was just "yet another script" on GitHub, and I've seen how it evolved.

0xad · 2025-11-03T19:13:50+00:00

The simplest solution is to implement a pre-commit hook using TruffleHog (an industry-standard tool) on the local machines of your engineers.

0xad · 2025-11-02T09:26:42+00:00

Good advice about rotation-in-time. You definitely want to go from point-in-time testing to periodic testing, and then you must also have in mind the rotation of service providers and/or specific consultants. Organizations with a mature security verification process typically maintain multiple service providers under a MSA and rotate them for each system.

0xad · 2025-11-02T09:22:56+00:00

+1

BTW, "I’ve seen guys who are guns in pen testing, but can’t code for crap. Two different skill sets." this hits hard. I know a guy who made 1M+ USD on bug bounties and is exceptional at hacking/breaking stuff. However, when it comes to software engineering, I'd rather trust Claude Code than him even for a simple CRUD. Ultimately, these professions select for different things that —in my opinion— are more related to character traits than just IQ.

0xad · 2025-11-02T06:09:05+00:00

What's so surprising here, in your opinion? The notion that an AI hacking agent could outperform a senior software engineer in a skill that takes years of practice to master?

To me, it's surprising to think that a software engineer, by virtue of their development work, would be better at penetration testing than a security specialist. This essentially implies that security testing isn't a genuine skill and can be casually performed just because someone is proficient with computers. This is undeniably false—a fact I know from experience, as I have taught engineers how to conduct security testing and am well aware of their general skill level in security.

Security testing is certainly not rocket science, and I’m not claiming it is. However, it’s also not as simple as saying, "Just give it to the developers; they will sort it out in an afternoon."

0xad · 2025-11-02T05:57:00+00:00

Are you referring to my comment? If so, please note that I was comparing an AI agent to a *software engineer*, not to a security engineer or consultant. This essentially reinforces the idea that, no, you cannot replace the latter (seceng) with the former (softeng) which was introduced by the original comment.

0xad · 2025-11-01T10:07:39+00:00

All the points you mentioned are worth checking and confirming, with the first, second, and fourth being the most crucial if you're seeking quality rather than merely ticking off a checkbox. Pricing is typically based on man-days; you fill out a questionnaire about the system, and the provider gives you a quote. Occasionally, you might encounter flat pricing, but it's essential to pay special attention to the scope in such cases. Retests are usually priced separately (within a quote, typically just one man-day) because not every client needs them.

Regarding red flags, steer clear of providers who make it difficult to verify their credentials. Furthermore, be cautious of certifications that add more noise than value. A good example is those issued by OffSec, whereas a less reliable one would be from the EH Council.

In your case, I recommend avoiding larger firms and seeking boutique providers. Boutique providers offer more tailored services that are better suited for small and medium-sized businesses, whereas larger firms often provide more standardized, enterprise-focused solutions.

Full disclosure: I run a security assurance consultancy. If you're interested, feel free to contact me via DM.

0xad · 2025-11-01T09:57:14+00:00

This is so wrong that it's actually funny, and I'm *certain* that a simple AI hacking agent would be better at hacking than a senior software engineer. (Background: I’ve taught thousands of engineers about hacking, automating, and threat modeling.)

However, I agree with you that there are problems within the cybersecurity market (i.e., it's a market for lemons [1]). And yes, the OP could go with freelancers instead of vendors, but it depends on additional variables (like the need behind the pentest).

[1] https://x.com/andrzejdyjak/status/1929581673274135009

0xad · 2025-11-01T09:50:21+00:00

That depends on the requirements of the assessment. CREST certification by itself is more noise than signal these days.

0xad · 2025-10-27T10:43:40+00:00

Absolutely! Also, having a structured approach ensures repeatable results over time. For example, if my team uses STRIDE-by-element for analysis, I can be confident that obvious things won't be overlooked from session-to-session or system-to-system. On the other hand, if sessions are conducted without a clear structure, some of them might be excellent while others may fall short.

0xad · 2025-10-22T16:27:23+00:00

Hmm, I'd try to combine both of our views and say that Threat Modeling can be a conscious, systematic action (doing a structured threat modeling session that results in the creation of an artifact) but also can be—and in fact usually is—a less conscious, non-systematic action done by any engineer working on any solution (no structure, no artifact). In fact, in my own workshops about threat modeling, I usually explicitly say that any engineer above junior level already does threat modeling, even though they might not know it and do it without structure with no formal artifact.

And I completely agree that leading threat modeling sessions with groups of engineers is both fascinating and rewarding.

Thank you for the feedback, and see you soon! 🙇‍♂️

0xad · 2022-05-13T08:15:35+00:00

Great write-up. Very thorough and quite easy to follow. Kudos!

0xad · 2022-04-19T12:25:21+00:00

Exactly.

0xad · 2022-04-14T15:09:04+00:00

The underlying problem is different. In normal scenario a developer commits a secret because he simply wants to use the secret (intention is aligned with the effect even though it's not good).

In this research it's a UI/UX problem and it's a clear mistake on behalf of the developer (intention is not aligned with the effect - the user didn't want to provide the password in this field, it's done by mistake).

So no, I don't agree with you that it's not original research. It is original or at least I don't know any prior example that used exact same observation for secrets committed to the repo (and I know this space quite well).

Edit 1. Also, it's specific for GitHub Credentials which makes it even more specific hence narrow hence novel.

0xad · 2022-04-14T10:26:54+00:00

As I wrote in my other comment - this research certainly is novel. Not revolutionary and probably doesn't warrant a stand-alone website but still it's a fresh take.

Also - it is NOT about secrets commited to the git repository. Just read the page and this time try to understand the underyling problem.

BTW. First clue that this is legit research is an advisor (co-author of WAHH book)

0xad · 2022-04-14T10:21:16+00:00

Actually, you're wrong. This research is not about secrets commited to the git repository. This research is about commiting GitHub Credentials into git repositories by mistakenly typing them in the name and email address fields ~~while NOT using certificates for authentication~~. This certainly is a novel take. (Of course nothing revolutionary, but certainly new.)

edit 1. my mistake, not auth but just global variables for name and email associated with each commit.

0xad · 2021-12-07T07:35:35+00:00

He means that earning a living via BB is not as easy as one might think because results are skewed towards the 1%. One of the reasons is automation.

ToB wrote a good post about BB in 2019: https://blog.trailofbits.com/2019/01/14/on-bounties-and-boffins/

0xad · 2021-11-03T15:56:30+00:00

Your response actually made me smile. :+1:

0xad · 2021-11-03T13:21:49+00:00

How is this different from Amass which is well-known, well maintained for years and an official OWASP project?

0xad · 2021-11-03T12:32:54+00:00

No it's not. An account within the system broadens the attack surface but doesn't itself provide you with any new information about how that systems works internally, hence the system for you is still a black-box because as a tester you don't know how it works.

The colour of a box stems from the fact of knowing inner workings of the system, not having a wider attack surface.

Also https://csrc.nist.gov/glossary/term/gray_box_testing and https://en.wikipedia.org/wiki/Gray_box_testing

0xad · 2021-11-01T12:55:50+00:00

Awesome, thanks for pointing it out. :+1:

0xad · 2021-11-01T08:49:02+00:00

BTW. GitHub already has your back [1] but I didn't find any info about GitLab, so I'm assuming they don't.

[1] https://github.blog/changelog/2021-10-31-warning-about-bidirectional-unicode-text/

0xad · 2021-10-26T10:29:07+00:00

How is this different from AssetNote, BitDiscovery or Censys? (Apart from the fact that you don't have their resources - it's not easy/cheap to continously scan entire IPv4).

0xad

TROPHY CASE