exposure-check Earns a 70 Proof of Usefulness Score by Building an Open-Source Exposure Scanner

Welcome to the Proof of Usefulness Hackathon spotlight , curated by HackerNoon’s editors to showcase noteworthy tech solutions to real-world problems. Whether you’re a solopreneur, part of an early-stage startup, or a developer building something that truly matters, the Proof of Usefulness Hackathon is your chance to test your product’s utility, get featured on HackerNoon, and compete for $150k+ in prizes. Submit your project to get started ! Today, we are interviewing Baris KECECI, the creator of exposure-check , an open-source security scanner that helps developers and security teams find leaked secrets and risky workflows before attackers do. With no agents or SaaS requirements, this powerful tool allows organizations to quickly audit their public attack surface directly from their CI/CD pipelines. What does exposure-check do? Open-source exposure scanner that finds what attackers can see before you do. Scans GitHub organisations, repositories, and domains for leaked secrets, risky GitHub Actions workflows, exposed corporate emails, and domain exposure. Single binary, no agents, no SaaS — runs locally, inCI/CD, or through a built-in web dashboard. Now’s a good time for exposure-check to exist because organizations are increasingly relying on decentralized CI/CD workflows and public repositories, making automated, locally-run secret scanning more critical than ever to prevent catastrophic data breaches. What is your traction to date? How many people does exposure-check reach? The project reaches security engineers, DevSecOps teams, and open-source maintainers through GitHub, HackerNoon (where I am ranked among the Top 10 Cybersecurity Writers), DEV.to, and LinkedIn. Combined monthly reach across these platforms is approximately 2,000-3,000 people through articles, repository visits, and social engagement. Who does your exposure-check serve? What’s exciting about your users and customers? Security engineers who need to audit their GitHub organisations for leaked secrets and risky workflows. DevSecOps teams integrating exposure scanning into CI/CD pipelines. Open-source maintainers who want to check their repositories for accidentally committed credentials. Red teams and penetration testers performing external reconnaissance. Startups and small teams that cannot afford commercial secret scanning tools but need visibility into their public exposure. What technologies were used in the making of exposure-check? And why did you choose ones most essential to your techstack? To ensure a lightweight and highly portable tool, exposure-check was built using Go, allowing it to compile down to a single binary with zero dependencies. It also leverages Docker and GitHub Actions for seamless CI/CD integration, and utilizes SARIF (Static Analysis Results Interchange Format) to standardize security finding reports for modern development workflows. What is traction to date for exposure-check? Around the web, who’s been noticing? The project is gaining solid visibility across developer communities, evidenced by comprehensive tutorials on DEV.to and active social engagement on LinkedIn. Furthermore, the tool's practical distribution—publishing v0.3 of its GitHub Action and hosting a Docker image on GHCR—shows growing adoption among DevSecOps professionals. exposure-check earned a 70 proof of usefulness score ( https://proofofusefulness.com/report/exposure-check ) - how do you feel about that? Needs to be reassessed or just right? A 70 is fair for where the project stands today. exposure-check is a working tool with a published GitHub Action, Docker image, and web dashboard — but it is still early in terms of community adoption. The score reflects that honestly. I expect it to improve as more teams integrate it into their workflows and contribute back to the project. What excites you about exposure-check's potential usefulness? Most organisations do not know what they are exposing publicly until an attacker finds it first. exposure-check solves this by scanning GitHub repositories, organisations, and domains for leaked secrets, risky CI/CD workflows, exposed corporate emails, and forgotten infrastructure — all from a single binary with zero dependencies. It runs locally, in CI/CD pipelines as a GitHub Action, or through a built-in web dashboard. The tool produces a posture score and prioritised findings that teams can act on immediately. It is particularly useful for small teams and startups that cannot afford commercial secret scanning tools but still need visibility into their public attack surface. Walk us through your most concrete evidence of usefulness. The tool detected hardcoded AWS credentials in a public repository during a security audit — credentials that had been committed two years earlier and forgotten. That single finding justified the entire project. Secret scanning is not about volume of findings; it is about catching the one credential that would have given an attacker full access to production infrastructure. How do you measure genuine user adoption versus "tourists" who sign up but never return? For an open-source CLI tool, retention means repeated usage — not logins. The strongest signal is CI/CD integration: when a team adds exposure-check to their GitHub Actions workflow, it runs on every push and pull request automatically. That is not a tourist. That is a permanent part of their security pipeline. I track this through GitHub Action marketplace usage and Docker pull counts. If we re-score your project in 12 months, which criterion will show the biggest improvement, and what are you doing right now to make that happen? Evidence of Traction. The tool is technically complete for its current scope — v0.3 covers secret detection, GitHub Actions auditing, domain exposure, and CI/CD gating. The next 12 months are about adoption: more GitHub stars, more CI/CD integrations, more contributors, and community-driven detection rules. I am actively publishing technical content on HackerNoon and DEV.to to drive awareness and contributions. How Did You Hear About HackerNoon? I have been publishing technical articles on HackerNoon since mid-2026 and was ranked among the Top 10 Cybersecurity Writers within my first week. HackerNoon has been an excellent platform for reaching a technical audience that values engineering depth over marketing. The Proof of Usefulness hackathon was a natural next step. Given that your GitHub Action is published at v0.3 and your Docker image is live, how many repositories or organizations are actively running exposure-check in their CI/CD pipelines each month? The project is in early adoption. A small number of teams are running it in CI/CD, primarily through the GitHub Action. The focus right now is on growing that number by making integration as simple as possible — three lines of YAML is all it takes to add exposure-check to any GitHub Actions workflow. You mentioned reaching 2,000-3,000 people monthly through articles and social engagement; what is your strategy for converting those readers into active open-source contributors and maintainers for exposure-check? Every check in exposure-check is a small, self-contained Go file. That is by design — it lowers the barrier for contribution. A security engineer who knows one secret pattern can add a detection rule without understanding the entire codebase. I highlight this in every article and in the README. The goal is to make contributing feel like adding a recipe to a cookbook, not modifying an engine. Since exposure-check is designed to help startups and small teams that cannot afford commercial tools, can you share a specific instance where the tool uncovered a critical exposed secret before an attacker did? During an external assessment for a development team, exposure-check flagged a PostgreSQL connection string with plaintext credentials committed in a configuration file that had been public for over a year. The team had no idea it was there. The credentials were still valid. That is the scenario exposure-check is built for — finding the things that are hiding in plain sight, before someone with bad intentions finds them first. Meet our sponsors Bright Data: Bright Data is the leading web data infrastructure company, empowering over 20,000 organizations with ethical, scalable access to real-time public web information. From startups to industry leaders, we deliver the datasets that fuel AI innovation and real-world impact. Ready to unlock the web? Learn more at brightdata.com . Neo4j: GraphRAG combines retrieval-augmented generation with graph-native context, allowing LLMs to reason over structured relationships instead of just documents. With Neo4j, you can build GraphRAG pipelines that connect your data and surface clearer insights. Learn more . Storyblok: Storyblok is a headless CMS built for developers who want clean architecture and full control. Structure your content once, connect it anywhere, and keep your front end truly independent. API-first. AI-ready. Framework-agnostic. Future-proof. Start for free . Algolia: Algolia provides a managed retrieval layer that lets developers quickly build web search and intelligent AI agents. Learn more .