Disclosure: I work at Knowverse, the company behind TechDD. This post is about our own event.
I'm not a developer. I sit next to the people who build our code-checking tools, and over the past few months I've watched them run the same three checks on almost every codebase that comes through the door. Small startups, solo builders, teams getting ready for investor due diligence — the same three problems keep showing up.
This month we have a reason to give that check away. Knowverse was selected for KAIST OverEdge Top 25, and to say thank you, our Security Triple Check is free from Nov 4 to Dec 3, 2026 (KST). It's normally $119.
But first, here's what the three checks are, and how you can run a basic version of each yourself today, for free.
1. Leaked secrets
API keys, database passwords and tokens that ended up in the code — or in the git history, even after someone deleted them from the current files. This is the one our engineers say people are most surprised by, because "I removed it last week" doesn't mean it's gone.
Try it yourself: gitleaks scans a repository, including its history.
gitleaks detect --source .
2. Vulnerable open-source dependencies
Most of a modern app is other people's code. If one of those packages has a known vulnerability, your app has it too, even if your own code is perfect.
Try it yourself: your package manager probably already has an audit command.
npm audit # Node.js
pip-audit # Python (pip install pip-audit)
3. Risky code patterns
Things like SQL queries built by gluing strings together, eval on user input, or TLS certificate checks switched off "just for testing" and never switched back on.
Try it yourself: Semgrep has free community rules for many languages.
semgrep scan --config auto
So why would you use ours?
Honestly, if you're comfortable running and reading the three tools above, you may not need it. What the Security Triple Check adds is one report that puts all three together and explains each finding in plain language, so it's easier to decide what to fix first. That's the part I personally find useful as a non-developer.
A few things people usually ask about their source code:
- It's analyzed only in an isolated environment.
- It's never sent to external AI services.
- It's deleted automatically when the assessment ends.
How the free check works
- Enter with your email and a company, team, or personal project name. Side projects are welcome.
- A free voucher goes onto your account right away. It's valid for 7 days.
- Upload your source code within those 7 days. The report arrives within 24 hours, in English.
- One entry per email account. No payment details.
- The only thing we ask in return: an honest review after you get your report. Criticism is welcome too.
👉 Enter for the free Security Triple Check
And a question for you, since I'm still learning: what's the one check you always run before you ship? I'd love to pass the answers on to our team.
Top comments (9)
This is a really transparent and helpful post. It's awesome that you're highlighting the exact open-source tools people can use for free (gitleaks, npm audit, semgrep) rather than just pushing your own product.
If I could add a few practical tips to your list for the developers reading this:
For secrets: Integrate gitleaks into a pre-commit hook (using the pre-commit framework) so they never even reach the remote git history in the first place.
For dependencies: Use Dependabot or Renovate. They automate the boring part of keeping packages updated and patch vulnerabilities before they become a problem.
For risky code patterns: Add Semgrep to your CI/CD pipeline. It’s one thing to run it locally, but blocking a PR automatically when someone uses eval or turns off TLS checks is a game-changer.
To answer your question: the one thing I always check before shipping is making sure my .env files are properly ignored and that no hardcoded API keys slipped into the latest commit.
By the way, I have to say, the girl featured in your promotional video/ad is absolutely beautiful!
Thanks so much, and thank you for answering my question too. The .env check is such a simple habit, and it's exactly the kind of thing I hadn't thought about as its own step before shipping.
What really clicked for me is your point about moving the checks earlier. In my post I described running the tools once and reading a report, but the pre-commit hook idea flips that: the secret never reaches the git history at all, so there's nothing to clean up later. That connects directly to what I mentioned about "I removed it last week" not meaning it's gone. Prevention beats cleanup, and I'm going to pass that to the engineers on our team.
Thanks for the kind words about the video too.
Quick follow-up, since you clearly have a routine: do you set those hooks up on every new project from day one, or only after something has slipped through once?
Honest answer: both, and in that order. Day one on every new project now, but the habit was born reactively — the first time I set one up was after something nearly slipped through, not before. So I'd be lying if I said it started as good practice.
What made it stick was putting the hook config in a template repo. New projects inherit it automatically, so it's not a decision anyone has to remember. On older projects I add it whenever I'm touching the repo anyway — cheaper than a dedicated cleanup sprint.
And thanks for the follow-up, this is a good thread. Glad the video landed too!
Thanks for the honest answer, especially the part about it starting reactively. That makes it feel a lot more real than "I always did it right from day one."
The template repo idea is what stuck with me most. In my post I talked about people running a check once and reading a report, but you're describing something different: the check lives inside the starting point, so nobody has to remember it. As a non-developer, that sounds like the same reason some AI habits last and others fade. If it depends on remembering, it usually doesn't survive. I'll pass that on to the engineers I sit next to, since I'd like to hear how they see it.
I also liked your point about adding hooks to older projects only when you're already in the repo. That's a much more realistic way to start than a big cleanup sprint.
Since you've clearly lived this: has a teammate ever pushed back on the hooks because they slowed down their commits, or did it just go smoothly?
Thanks! The "check lives inside the starting point" framing is exactly the goal — if a habit relies on someone remembering to do it, it's already dead.
To answer your question: yes, there's always some initial pushback. Nobody actually files a formal complaint, but you definitely get a grumble the first time a commit gets blocked because of a pre-commit hook. Engineers hate friction, and waiting a few seconds feels like a lot when you're in a flow state.
But the pushback usually disappears the first time the hook actually catches something — a leaked API key, a missing test, a broken import. That's when it stops being "the thing that slows me down" and becomes "the thing that saved us from a bad deploy."
One rule that helped us: make sure the hooks are fast. A 500ms check becomes invisible; a 30-second check will cause a mutiny. If it slows down the inner loop too much, people will just start using --no-verify out of spite.
Thanks for answering that so directly, and for the speed point in particular. "A 500ms check becomes invisible, a 30-second check causes a mutiny" is the clearest way I've heard it put.
What clicked for me is that the pushback goes away the first time the hook actually catches something. I'd been thinking of the value of a check as the report you read afterward. You're saying the value is felt in the moment, when it blocks you and you realize it just saved you. As a non-developer, I see the same pattern with AI tools: people only stick with them after the first time one saves them real time. Before that, it's just friction. And the --no-verify bit made me laugh, because skipping the step out of spite sounds a lot like people quietly going back to their old way of working.
I'll pass the speed rule to the engineers next to me. Quick question for you: have you ever used a tool at work that annoyed you at first but became something you'd miss if it disappeared?
Yes — code review approvals via a bot. It felt like bureaucracy at first, waiting for a checkmark on a Friday. Then one Thursday it caught a migration that would have renamed a column nobody expected, and suddenly it was the thing I trusted most on the team.
Your point about value being felt in the moment is exactly right. Nobody reads the report afterward — they remember the one time it stopped them.
Thanks for sharing that, and the migration story especially. A check that felt like bureaucracy on a Friday turning into the thing you trust most on the team after one Thursday save is exactly the pattern I was trying to describe, just from a side I haven't seen myself.
What stays with me is your last line: nobody reads the report afterward, they remember the one time it stopped them. In my post I framed the value as one clear report that explains findings in plain language. You're making me think the report matters less than the moment of being stopped. I'm a non-developer, so I'll admit I hadn't considered that the trust comes from a single memorable catch, not from steady usefulness. That's true of AI tools too, I think.
I'll pass this to the engineers I sit next to. Out of curiosity, on the non-code side of your work, is there any tool or routine that earned your trust the same way, after one moment where it saved you?
Spot on about the "one memorable catch". For me, it's automatic cloud backups. It felt like pointless overhead until the day I accidentally deleted a critical file and it restored it instantly.
You're exactly right—steady usefulness builds habits, but one memorable save is what actually earns trust.