My company is giving away its security check for a month — here is what it actually looks at

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.

Comments

[Oleksandr]

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!

[Seohyun Lee]

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?