DEV Community: Peter Nasarah Dashe

Most security tools still use 20-year-old rules. That's why I built Permi.

Peter Nasarah Dashe — Sun, 12 Apr 2026 13:24:10 +0000

The Problem

Old-school vulnerability scanners work like this:

If response matches pattern → safe
Else → unsafe

That logic was fine in the early 2000s. But modern systems are dynamic, complex, and full of legitimate edge cases. Those same tools now flood you with false positives.

You run a scan. It says 50 "critical" issues. You spend hours filtering. Only 8 are real. That's not security—that's a productivity killer.

What Permi Does Differently

Permi is an AI-powered vulnerability scanner built for today's development workflow.

Reduces false positives with intelligent filtering.
Works where you code – CLI now, VS Code & GitHub actions coming soon.
One command to scan websites or source code.


bash
pip install permi
permi scan --url https://your-site.com

##Early stage, honest feedback needed
Permi is still in early development. It's stable, but you might find rough edges. If something is confusing, broken, or missing:

Comment below or DM me.
Open an issue on GitHub.
Your feedback will directly shape Permi into the tool developers actually need.


  
    
      
      
        Peternasarah
       / 
        permi
      
    
    
      AI-powered vulnerability scanner for Nigerian developers and global SMBs
    
  
  
    


Permi





AI-powered vulnerability scanner for Nigerian developers and global SMBs.

Permi scans live websites and source code for security vulnerabilities, then uses AI to filter out false positives — so you only see findings that actually matter.

Built in Nigeria. For Nigeria. Then for the world.





Two scan modes




--url — Live web scanning


Point Permi at any website. It crawls the pages, tests for SQL injection, XSS, and checks security headers on the running application.


permi scan --url https://yoursite.com





--path — Static source code scanning



Point Permi at a local folder or GitHub repository. It reads your code files, matches vulnerability patterns, and flags issues before they ship.


permi scan --path ./myapp
permi scan --path https://github.com/user/repo




What Permi detects




Web scanning (--url)








SQL Injection — error-based, boolean-based blind, time-based blind



Cross-Site Scripting (XSS) — reflected XSS with context-aware testing



Missing Security Headers — HSTS, CSP, X-Frame-Options, X-Content-Type-Options

…





  


  View on GitHub




  
  
  Links


PyPI: pip install permi

GitHub: peternasarah/permi

Let's kill false positives together. 🔥 

 Permi CLI scanning a live URL for vulnerabilities

250 Clones in 4 Days! Thank You 🙌

Peter Nasarah Dashe — Sat, 11 Apr 2026 14:09:01 +0000

Permi just hit a huge milestone, and I couldn't be more grateful. Now, I need your help to make it even better.

I'm building this in public, and your feedback is the most valuable tool I have.

How is your experience so far?

If you've run permi scan, please leave a comment with one of these words:

🔴 "broke" – if something crashed
🟡 "confusing" – if it wasn't clear
🟢 "useful" – if it helped

Alternatively, feel free to DM me with specific details. No pitch—just trying to build something helpful.

Peternasarah / permi

AI-powered vulnerability scanner for Nigerian developers and global SMBs

Permi

AI-powered vulnerability scanner for Nigerian developers and global SMBs.

Permi scans live websites and source code for security vulnerabilities, then uses AI to filter out false positives — so you only see findings that actually matter.

Built in Nigeria. For Nigeria. Then for the world.

Two scan modes

`--url` — Live web scanning

Point Permi at any website. It crawls the pages, tests for SQL injection, XSS, and checks security headers on the running application.

permi scan --url https://yoursite.com

`--path` — Static source code scanning

Point Permi at a local folder or GitHub repository. It reads your code files, matches vulnerability patterns, and flags issues before they ship.

permi scan --path ./myapp
permi scan --path https://github.com/user/repo

What Permi detects

Web scanning (`--url`)

SQL Injection — error-based, boolean-based blind, time-based blind
Cross-Site Scripting (XSS) — reflected XSS with context-aware testing
Missing Security Headers — HSTS, CSP, X-Frame-Options, X-Content-Type-Options
…

View on GitHub

Open an issue on GitHub

250 Clones in 4 Days: A Student's Journey Building an AI Security Tool

Peter Nasarah Dashe — Tue, 07 Apr 2026 12:07:05 +0000

🚀 250 Clones in 4 Days: A Student's Journey Building an AI Security Tool

By Nasarah Peter Dashe

Cybersecurity Student @ UNIJOS | Founder of Permi

The Numbers That Surprised Me

On April 2nd, 2026, I did something terrifying.

I typed pip install permi into my terminal, ran a few final tests, and hit publish on PyPI. A vulnerability scanner built by a student with no funding, no team, and no prior accomplishments was now available for anyone in the world to download.

Four days later, GitHub told me something I didn't expect:

250 clones.

62 developers per day, on average, downloading Permi. Testing it. Breaking it. Some even giving feedback.

This isn't a Silicon Valley startup with millions in backing. This is a cybersecurity student at the University of Jos, building in public, one commit at a time.

The Problem That Wouldn't Leave Me Alone

I've spent hours staring at security scan reports. You know the kind: 47 "critical" vulnerabilities flagged, only 4 of them real. The rest? False positives. Misconfigurations that don't apply. Warnings about libraries I wasn't even using.

That's not security. That's noise.

And noise has a cost:

Developers learn to ignore alerts
Real vulnerabilities slip through
Breaches happen

The recent LiteLLM supply chain attack proved that even the tools we trust to secure us can become the vulnerability. Three security tools compromised in five days using the same stolen credentials. The attacker didn't exploit the tools – they exploited the CI/CD access those tools had.

I saw this gap and couldn't unsee it.

Nigerian developers and SMBs are stuck with expensive, complex tools built for Western enterprises. Tools that don't understand our local fintech APIs, our hosting constraints, or the unique threats we face. Tools that interrupt our flow instead of supporting it.

So I decided to build something different.

What Permi Is (And Isn't)

Permi is an AI-powered vulnerability scanner designed for one job: meet developers where they already work.

Feature	Status
`pip install permi`	✅ Live
CLI scan command	✅ Live
Web vulnerability detection (SQLi, XSS, etc.)	✅ Live
AI false-positive classifier	🚧 In progress
VS Code extension	🔜 Planned
GitHub Action	🔜 Planned

One command to scan a website:

pip install permi
permi scan --url https://example.com

No context switching. CLI first, with IDE integrations coming soon.

AI that actually helps. False-positive filtering, remediation suggestions, risk prioritization.

Built for Nigeria first. Affordable pricing, local vulnerability checks, NDPR compliance mapping.

Permi isn't trying to replace every security tool. It's trying to fix the parts that frustrate developers most.

What 250 Clones Tell Me

Numbers without context are just numbers. Here's what these 250 clones mean to me:

1. The problem is real

Developers don't clone random repos. They clone tools they intend to use or learn from.

2. My announcement worked

The spike of 70 clones in a single day came right after I shared Permi on social media. Community matters.

3. Word of mouth is happening

250 clones in 4 days means people are sharing my link. I don't have a marketing budget. I have developers who see value.

4. I'm no longer "pre-product"

An investor recently told me Permi had "no traction." Now I have evidence that the market disagrees.

What I've Learned (In Just 4 Days)

Shipping is everything.

An imperfect product in the wild is infinitely more valuable than a perfect product in your head.

Traction talks.

No amount of pitch deck polish replaces a developer typing pip install permi and running your code.

Community is my unfair advantage.

Senior security leaders accepted my connection requests. Practicing security analysts took time to explain real-world misconfigurations like .env leaks and dependency confusion. Security companies engaged with my posts.

These aren't just names. They're people who saw a student trying to build something real and decided to help.

What's Next for Permi

The MVP is live. Now I'm building:

AI false-positive classifier – cut the noise by 80%
VS Code extension – real-time scanning as you code
GitHub Action – automatic PR comments and blocking
API scanner – for fintechs and backend teams

I've also applied to the iDICE Founders Lab – a ₦10 million grant program for early-stage Nigerian founders. If selected, I'll use the funding to focus on Permi full-time, hire a part-time developer, and reach our first 500 paying users.

I Need Your Help

I'm not writing this to brag about 250 clones. I'm writing this because I genuinely believe the best products are built with the community, not in isolation.

So here's my ask:

If you're a developer, founder, or security professional:

Try Permi:

   pip install permi
   permi scan --url https://your-site.com

Break it. Tell me what's missing, what's confusing, what's broken.
Share this post with one person who struggles with security noise.

And if you've ever ignored a security alert because you've been burned by false positives before – drop a comment. I want to hear your story.

One Last Thing

Four days ago, Permi was just a PyPI package.

Today, it's been cloned 250 times.

Tomorrow, I'm back to building.

Because that's what founders do. We ship, we learn, we iterate. And we do it in public, so everyone can see that a student at UNIJOS with no funding can still build tools that matter.

pip install permi and let's secure Nigeria's developers, one scan at a time.

🔗 Links

GitHub: github.com/peternasarah/permi
PyPI: pypi.org/project/permi
Twitter/X: @peternasarah
Permi: https://peternasarah.github.io/permi

🏷️ Tags

cybersecurity devsecops opensource python buildinpublic supplychainsecurity

The Vulnerability Scanner That Became the Vulnerability

Peter Nasarah Dashe — Tue, 31 Mar 2026 21:27:31 +0000

The Story

A vulnerability scanner got hacked.

Then the hackers used it to poison one of the most popular AI libraries on the planet.

That happened last week.

Here's what went down:

March 19 — TeamPCP compromised Aqua Security's Trivy, one of the most trusted open-source vulnerability scanners in DevSecOps.

March 23 — Using stolen credentials, they compromised Checkmarx's KICS GitHub Actions and VS Code extensions.

March 24 — Those same credentials gave them access to LiteLLM's CI/CD pipeline.

What Is LiteLLM?

LiteLLM is the universal AI gateway used across 36% of all cloud environments. It averages 95 million downloads per month. It sits between applications and 100+ AI providers—holding API keys for OpenAI, Anthropic, AWS, and Azure in one place.

The attackers published two backdoored versions to PyPI.

What the Malware Did

In just three hours, the malware:

Harvested SSH keys, cloud credentials, and Kubernetes secrets
Deployed privileged pods to every node in Kubernetes clusters
Installed a persistent backdoor polling for additional payloads
Swept cryptocurrency wallets and .env files

TeamPCP posted this on Telegram:

"These companies were built to protect your supply chains yet they can't even protect their own."

They also announced a partnership with LAPSUS$.

Let that land.

The Irony That Kills

Victim	Their Job	What Happened
Aqua Trivy	Vulnerability scanner	Got hacked
Checkmarx KICS	Infrastructure as Code security	Got hacked
LiteLLM	AI gateway with 95M downloads	Got backdoored

The companies selling supply chain security became the supply chain risk.

What This Means for Developers

If Trivy, KICS, and LiteLLM—with all their resources and visibility—can be compromised this way, what does that mean for the rest of us?

More importantly: What should we be asking our security tool providers right now?

I'm a cybersecurity student at UNIJOS, and I've been sitting with this question all week.

The Question I Keep Coming Back To

If you're using security tools in your workflow—scanners, CI/CD integrations, AI libraries—what's one thing you wish you knew about their security before you started using them?

Not asking for product pitches. Genuinely trying to understand how developers and security professionals are thinking about this.

Drop your thoughts in the comments. I'll read every single one.

A Quick Reflection

This attack reinforced something for me:

Firewalls aren't enough. Tools aren't enough. Even the tools built to protect us need to be secured.

If we're building on top of AI infrastructure, we have to start asking harder questions about the tools we trust—because right now, the attackers are asking the right questions.

Let's learn together.

If you found this helpful, consider sharing it with someone who's building on AI infrastructure. We need to have this conversation.

Reducing False Positives in XSS Detection: Designing Confirmation-Based Scanners

Peter Nasarah Dashe — Thu, 26 Feb 2026 23:53:23 +0000

Most beginner vulnerability scanners detect XSS using a simple pattern:

Inject payload
Check if payload appears in response
If yes → flag vulnerability

This approach is fast. It is also deeply flawed.

In real-world applications, reflection alone does not equal exploitability. Reflection without context analysis leads to massive false positives.

In this article, I'll walk you through a structured approach to reducing false positives in reflected XSS detection.

The Core Problem: Reflection ≠ Execution

A payload appearing in the response does not mean:

It executes
It appears in a dangerous context
It bypasses encoding
It breaks out of attributes or scripts

For example:

<p>You searched for: &lt;script&gt;alert(1)&lt;/script&gt;</p>

A naive scanner flags this. But the payload is HTML-encoded. There is no XSS. Yet many tools still report it.

Designing a Confirmation-Based Detection Model

Instead of binary reflection checks, a structured scanner should:

Inject a uniquely identifiable marker
Analyze where it appears
Classify context
Confirm exploitability conditions
Only then report

This changes detection from pattern-matching to context validation.

Step 1: Unique Marker Injection

Instead of injecting generic payloads like:

<script>alert(1)</script>

Use uniquely identifiable markers:

PERMI_XSS_9fA21

This allows precise reflection tracking without accidental matches.

Step 2: Context Classification

Where did the marker appear?

Inside HTML body text
Inside attribute value
Inside JavaScript block
Inside HTML tag name
Inside comment
Inside encoded output

Each context has different exploitability rules.

Safe contexts:

Fully HTML encoded
Inside comment
Inside text node without script context

Potentially dangerous contexts:

Inside unquoted attribute
Inside JavaScript string
Inside event handler
Inside script block

Context matters more than reflection.

Step 3: Encoding Detection

Before reporting, confirm:

Is < encoded?
Is " encoded?
Is ' encoded?
Are special characters escaped?

If the payload is consistently encoded, it should not be flagged.

A confirmation-based engine checks transformation patterns instead of blindly matching strings.

Step 4: Multi-Step Validation

Instead of one payload, use controlled variations:

Plain marker
Attribute-breaking marker
Script-breaking marker

If only the plain marker reflects but breaking payloads do not alter structure, likelihood of exploitation decreases.

This moves detection toward probabilistic validation.

Moving Beyond Rule-Based Logic

Traditional scanners operate with:

if reflected:
    report

A better approach introduces weighted scoring:

confidence = (
    (reflection_weight  * 0.3) +
    (context_weight     * 0.4) +
    (encoding_bypass    * 0.2) +
    (breakout_success   * 0.1)
)

Only report if the score exceeds a defined threshold. This reduces false positives dramatically.

Why This Matters

False positives have real consequences:

Developer fatigue
Security team distrust
Ignored reports
Delayed remediation

Precision builds trust. Noise destroys it.

If developers repeatedly see inaccurate reports, they stop believing the scanner.

A well-designed tool should prefer fewer findings at higher confidence over massive noisy output.

Architectural Considerations

To support confirmation-based scanning:

Separate scanner modules from UI
Centralize evidence formatting
Use structured vulnerability models
Keep payload sets modular
Avoid embedding logic inside GUI layers

Clean architecture makes improvement possible. Messy architecture locks in technical debt.

The Bigger Picture

Reducing false positives is not about clever payloads. It's about:

Context understanding
Confirmation logic
Structured scoring
Thoughtful design

Security tooling should evolve from brute-force injection engines to intelligent validation systems. That's where the real engineering challenge lies.

Final Thoughts

If you're building a scanner, don't ask: "Did it reflect?"

Ask: "In what context did it reflect, and does that context allow execution?"

The difference between those two questions is the difference between noise and intelligence.