Key concepts
The terms you'll see across Lighthouse, in the order you'll meet them.
This page explains the ideas behind Lighthouse in about five minutes. For one-line definitions, use the glossary.
Team and roles
Your team is your organization in Lighthouse. It owns the repositories, members, API keys, settings, and credits. Each person belongs to one team, with one of two roles:
| Role | Can do |
|---|---|
| Admin | Everything: GitHub connection, repositories, members, API keys, and team settings. |
| Developer | Work with the repositories they can access: run ingestions, enhance prompts, read scans. |
An admin can also make a developer the maintainer of a repository. A maintainer manages that one repository's settings, access, and branches.
Repositories and branches
A repository is a GitHub repository your team tracks in Lighthouse. The CLI calls it a project. Both words mean the same thing.
Lighthouse keeps everything per branch. Each branch has its own security cards, scans, and history. Every repository has a default branch, usually main, which Lighthouse uses when a branch has nothing of its own.
Ingestion and security cards
An ingestion reads one branch at one commit and works out its security rules. Each rule is a security card.
Cards come in two kinds:
| Kind | Comes from | Example |
|---|---|---|
| Local card | Your own code, learned by ingestion. You can edit or delete it. | "Every route under /admin must call require_admin." |
| Global card | Lighthouse's catalog of guidance for open source libraries, matched to the versions you use. | Safe settings for your version of Django. |
A branch uses only the cards from its most recent completed ingestion.
Prompt enhancement
Enhancement adds the relevant security cards to your coding request before your agent sees it. Each added piece of guidance is a security point. Many are tagged with a CWE, the standard ID for a type of weakness (CWE-89 is SQL injection).
The dashboard lists enhancements under Guardrails. A guardrail and an enhancement are the same thing.
Scans and findings
A scan reviews a code change for security problems:
- A pre-commit scan runs when you
git commitand reviews your staged changes. - A pull request scan runs on GitHub and reports back as a check on the pull request.
Each problem a scan reports is a finding. Every finding has a severity: critical, high, medium, or low.
Blocking and fail-open
The blocking policy sets the severity that stops a commit or a merge. With High+, a high or critical finding blocks, while medium and low findings are reported only. Each repository has one policy for commits and another for merges.
If Lighthouse can't finish a scan (it's down, the request times out, or your team is out of credits), the commit or merge goes ahead. This is fail-open. Lighthouse never blocks you because of its own problems.
Exceptions and false positives
A scan exception is a sentence describing something intentional in your code that scans should stop reporting. For example: "/login is public by design and needs no authentication."
A false positive is a finding someone has marked as not a real problem. It no longer counts toward blocking.
Credits
Credits measure the AI work Lighthouse does for you. Ingestions, enhancements, and scans use them. Your team's plan sets how many you can use each month. See Credits and plans.