Pitangus

About Pitangus

Pitangus is a self-hosted, open-source application security tool for small teams. It finds problems in code, dependencies, secrets, infrastructure, container images and the sites you verify, and it counts a fix only when a later scan proves it.

Why it exists

Small teams answer the same security questionnaires and audits as large companies, without a security team. The tools within their reach tend to fall into two groups: a long list of alerts nobody has time to sort, or a service their code has to be sent to.

Pitangus takes the open-source engines those teams already trust, runs them on their own server, merges what they find into one registry without duplicates, and keeps what an auditor asks for: when each finding appeared, who decided what about it and why, and which scan proved it gone.

Who is behind it

Pitangus is made by Arodium, a small team in Colombia. For clients we build software (custom, mobile, web and e-commerce), integrate data, AI and business systems, run cloud and DevSecOps work, and do security testing: pentesting, application and code security, and cloud security reviews. We also develop our own products, and Pitangus is one of them: it comes from that security practice.

The project is in beta: what each release changes, including what breaks, is in the changelog.

Changelog

Principles

Self-hosted
It runs on your server with Docker. Your code and your findings stay there.
No telemetry
Nothing is sent to us. It only reaches public advisory data, the image registries you scan, the domains you verify, the services you connect and, if you turn them on, OSV and your secrets’ own providers.
Proves fixes
A finding is fixed when a later scan, whose engines finished, no longer finds it. If an engine fails or is turned off, the scan says so and nothing it covers counts as fixed.
Never invents fixes
The fix shown is the tool’s own text, followed by links to the OWASP pages that apply. Pitangus doesn’t write remediation of its own.
Open source
GNU AGPL-3.0. Read every line, change it and run it without asking. Its SAST rules are MIT, so other tools can reuse them.

How to contribute

Report a problem or ask
Open an issue on GitHub. Say what you ran, what you expected and what happened; never paste tokens or unreviewed logs.
Report a vulnerability
Privately, as the security policy explains. Not in a public issue.
Change the code
Open an issue first for big changes, then a pull request. The contributing guide lists the checks; your first pull request asks you to accept the contributor agreement.
Spread the word
If Pitangus helps your team, a star on GitHub or a mention helps other small teams find it.

Contact

Questions, ideas and problems go to GitHub issues, where answers stay public for the next person who asks.