StackSecure originated as a bootstrapped passion project. We're a group of friends & colleagues coming together from diverse professional backgrounds, passionate about provising affordable SAST to all. Many of us came from software engineering, DevOps, or AI/ML academia. I've been really grateful to sit on the other side of the table with these folks, working to create unique & timely SAST detections for future customers.

As a red team lead by day, practicing and training through bug bounty has always been an effective way to acquire and maintain a realistic skillset. Pivoting to traditional security research (where one may be awarded a CVE, instead of a bounty payout), can oftentimes be closer than expected, unintentional, and uniquely rewarding. Likewise, the experience gained is priceless, understanding how to discover, leverage, and mitigate vulnerabilities beyond misconfiguration.

Earlier this year, I discovered an exploitable vulnerability on a public-facing web app. A common occurance at times in my line of work, but what made this one different was the root cause. After some in-depth validation on my part, it turned out to be a SAST finding discovered from the other side, public-facing & in production.

Coming from bug bounty, the reporting process for this was distinctly unique. My goal with this series is to not only to raise awareness of where SAST vulnerabilities can surface in production, but to provide resources, either my own or with proper citations for the everyday security researcher.

This will be the first of more to come where I'll talk about my journey, bridging offensive security and SAST - this is Offensive Security Uncovered :)

The Workflow

So here you are, fellow researcher... you're participating in a bug bounty program and your findings were identified to be out-of-scope. But fear not! As you read the response from triage, you're forwarded to the software vendor for further analysis. You've found your first potential CVE and its time to report, congrats!

Should be a straightforward and easy process, right?

Before submitting a request to MITRE, you must determine if the target application is managed by a CVE Numbering Authority (CNA).

• A CNA is a vendor (such as Adobe or specific software companies) authorized by MITRE to assign their own CVE IDs.
• If the product belongs to a CNA, you must request the CVE ID directly from that vendor rather than MITRE.
  • If you are interested in how a vendor becomes a CNA, I stumbled upon a document from NIST explaining the entire process, NISTIR 8246.

Identifying the CNA​

There are a few ways you can identify a CNA. If you are an ethical hacker or red teamer, think of this as an extention to the reconnaisance or discovery operations phase.

1. Use the List of Partners Search Engine hosted on cve.org.

   • You'll want to search for CNA & CNA-LR (CVE Numbering Authority of Last Resort)

2. Dork for security.txt

   

   inurl:/.well-known/security.txt (company-name-here) 
   inurl:/.well-known/security.txt filetype:txt (company-name-here)
   inurl:/.well-known/security.txt filetype:txt site:domain.tld
   
   • Security.txt files assist ethical hackers and security researchers with responsibly disclosing their findings.
     • IANA standardized the format in RFC 9116 to assist site owners in collaborating with security researchers.
     • The format gained populatity prior to standardization with RFC 9116 in a 2021 evaluation by Tara Poteat & Frank Li at Georgia Institute of Technology. The evaluation highlighted its potential, but lack of implementation across domains at the time. Hence, the need for alternative search methods arose.

3. Use alternative search engines

   • A handful of specialized search engines have arose for responsible disclosure contacts.

     • Disclose.io - Open-Source, offers a search engine for their security contact database

       • Front-end for their open-source dataset, diodb

     • Well-Known Resource Index

       

       resource:"security_txt" base_domain:google.com
       

     • GitHub Code Search

       

       path:**/SECURITY.md org:google
       

     • A SECURITY.md file is a standard document placed in the root or .github directory of a code repository to inform users and security researchers how to handle and report security issues.

Writing The Report​

The report writing process can vary greatly based on the problem type and impact of the vulnerability. Depending on the CNA, the quality of their reporting portal can vary as well. If you are a developer, think of this as the user experience (UX) for ethical hackers. As an ethical hacker, it isn't uncommon to feel lost or unsupported in this process. The first time I did this, it actually slowed down my report and required extra research on my end.

Reporting Template​

I ended up using a template created by Evan Issac of MRE Security. He also has a really awesome video around this process. Check it out!

# [Vulnerability Name]

#### Severity Score: [Severity]
#### CVSS Score: [CVSS Score]

## Description

[Description About the Vulnerability]

## Impact

[Impact Statement]

### POC

[Reproduction Steps]

## Remediation

[Remediation Steps]

Who We Are​

At StackSecure, we believe code and application security scanning should be automated, useful, and observable—without the complexity and cost that often come with traditional security tooling.

Founded by Riley Louvier, a veteran full-stack startup engineer, StackSecure was created to solve the inefficiencies and shortcomings of modern code security solutions. Most security scanners just felt out-of-date, weren't much of a pleasure to use, or didn't offer relevant data. So far, we've developed everything with two very ambitious full-stack engineers.

We certainly acknowledge we're going against some rather established players in the industry. We truly think you just might like our approach better! 👀

Similar security tools like Snyk, Aqua, and Aikido tend to focus on specific areas, such as open-source vulnerabilities (Snyk) or enterprise-heavy compliance solutions (Aqua). Many of these tools lack comprehensive visibility and a smooth experience across an organization's entire security application landscape.

We’re here to change that.

We don't normally use this many emojis in our writings, but it sure helps break up all the text 😄

StackSecure delivers automated security scanning and real-time threat observability that gives organizations and users extensive insight into their security posture—covering code, applications, and cloud-native integrations. Our platform isn’t just about finding vulnerabilities—it’s about ensuring you can see trends, understand, and act on security risks.

What Makes StackSecure Different?​

Unique threat observability, security automation, and reporting is at the core of the StackSecure Suite’s competitive edges.

Here’s how we stand out just a bit from Snyk, Aqua, and Aikido (as well as a couple of others in this niche space):

Full-Scope Security Visibility

• Unlike Snyk (which tends to heavily focus on open-source threats) or Aqua (which primarily targets container security and enterprise-only security areas), StackSecure provides a complete security suite that covers SAST, MAST, Docker, IaC, and compliance reports— all in one place.

  Real-Time Security Data & Faster Threat Detection

• Our proprietary backend data ensures you’re not relying on outdated or irrelevant vulnerability databases. Unlike Aqua and Aikido, which primarily focus on batch security scans, StackSecure delivers real-time security insights with continuous monitoring—helping teams catch risks before they become critical.

  Deeper Code Security Insights

• While tools like Snyk are great at open-source dependency scanning, they lack full visibility into the most relevant threats. StackSecure’s SAST and MAST tooling work at both the code and runtime levels, giving developers actionable insights into security flaws—beyond just dependency issues.

  Actionable Security Fixes - Not Just Alerts

• Many security tools flood teams with alerts without clear fixes. StackSecure provides immediate, industry-standard remediation steps, reducing the burden on developers and security engineers.

  Clear Pricing & Easy Integration

• Unlike Aqua and Snyk (which tend to have complex pricing models and hidden costs), StackSecure provides transparent, flat-rate pricing. Our turnkey solution integrates seamlessly with any existing workflow.

What We're Building​

Security teams today don’t just need alerts—they need true visibility. StackSecure is designed to provide continuous, real-time threat observability across an organization's entire codebase, cloud infrastructure, and containerized environments via real-time SAST at it's very core.

Some of Our Current & Future Core Product Offerings​

Why We’re Building StackSecure​

We believe code and application security should be transparent, innovative, and offer a world-class UI/UX.

While competitors focus on automated security scans, we focus on providing better visibility, user experiences, and automated fixes.

If you’re a developer, a business, or a potential investor— we want your feedback as we build the future of automated code and application security tooling and scanning.

Are you looking for investors?​

...Of course we are! We're a SaaS startup made by two people. Please contact me personally via LinkedIn under the Who We Are section of this post - thank you!

Beta Invites & Contact​

StackSecure is currently in invite-only beta testing mode. Please use the Contact form if you're interested in an invite, or getting in touch!

Automated Security Scanning should be smarter, faster, and more transparent.

Follow our journey, share your thoughts, and help us build a better approach to application cybersecurity and automated code scanning.