When we work on a Laravel application, we usually spend a lot of time checking the application itself.

We check authentication, APIs, database queries, permissions, validation and server security.

But there is another important part that developers sometimes forget: the security of the GitHub repository where the application is developed and deployed.

Our GitHub repository can contain source code, GitHub Actions, deployment workflows, webhooks, secrets, release tags and access permissions. If these are not configured properly, the repository can become a security risk.

Laravel recently introduced Moat, a command-line security review tool for GitHub accounts, organizations and repositories.

I find this interesting because it focuses on something practical: instead of manually checking many GitHub settings, we can run a review and get a report about the current security configuration.

What is Laravel Moat?

Moat is a read-only security review tool.

It checks security-related settings that already exist in GitHub and reports configuration problems or missing protections.

It can review:

GitHub user accounts

GitHub organizations

GitHub repositories

The important point is that Moat does not automatically change our GitHub settings.

It tells us what should be reviewed, and we decide which changes make sense for our project.

Why GitHub security matters

For a normal Laravel project, GitHub is not just a place to store PHP files.

It can also contain:

Deployment workflows

GitHub Actions

Package releases

Webhooks

Deployment keys

Environment-related configuration

Pull requests

Repository access

Release tags

CI/CD permissions

For open-source Laravel or Composer packages, the impact can be even bigger.

A compromised maintainer account or workflow can potentially affect software that other applications depend on.

This is why repository security should be treated as part of application security.

What does Moat check?

Moat checks a number of GitHub security controls.

Some important examples are:

Two-factor authentication

Developer accounts should use strong authentication.

If an important GitHub account is protected only by a password, stealing that password can give an attacker access to repositories and other development resources.

2FA adds another layer of protection.

Branch protection

Important branches such as main should not always allow anyone to directly push code.

Branch protection can require pull requests, reviews and other checks before changes are merged.

This is especially useful for production repositories.

Signed commits

Signed commits help verify that commits were actually created by an expected developer identity.

This does not solve every security problem, but it can provide an additional layer of verification.

Secret scanning

Secrets accidentally committed to GitHub can become a serious problem.

Examples include:

API keys

Cloud credentials

Database credentials

Access tokens

Private keys

Secret scanning can help detect exposed credentials.

But developers should still avoid putting secrets inside source code in the first place.

Secret push protection

Preventing a secret from being pushed is generally better than discovering it after it has already reached the repository.

Push protection can help stop certain secrets before they become part of the Git history.

Dependabot

Dependencies are another important part of application security.

A Laravel application can depend on many Composer packages and frontend npm packages.

Keeping dependencies updated and monitoring security alerts can reduce the chance of continuing to use a vulnerable package.

GitHub Actions permissions

This is one area I think Laravel and PHP developers should pay more attention to.

GitHub Actions can deploy applications, access repositories, publish packages and interact with cloud services.

If a workflow has more permissions than it needs, a compromised workflow or third-party action may have a larger impact.

The principle should be simple:

Give CI/CD workflows only the permissions they actually need.

Pinned GitHub Actions

GitHub Actions often depend on third-party actions.

For example:

- uses: some-user/some-action@v1

A moving tag can change over time.

For security-sensitive workflows, pinning actions to a specific commit can provide stronger control over exactly what code the workflow executes.

This becomes especially important when a repository has automated deployment or package publishing.

Webhooks and collaborators

Repositories can also have webhooks and direct collaborators.

These are easy to forget because they are not part of our Laravel code.

But they can still provide access to external systems or people.

Regularly reviewing:

Repository collaborators

Organization members

Webhooks

Deploy keys

GitHub Apps

is a good security practice.

SECURITY.md

Open-source projects should also consider having a SECURITY.md file.

It gives security researchers a clear way to report vulnerabilities privately instead of opening a public GitHub issue.

For projects that are used by other developers, this small file can make the security-reporting process much clearer.

How I would use a tool like Moat

For my Laravel projects, I would treat this as a periodic repository security check.

A simple workflow could be:

Review the GitHub account security.

Check organization access.

Review production repositories.

Check branch protection.

Review GitHub Actions permissions.

Check third-party actions.

Review secrets and secret scanning.

Review collaborators and webhooks.

Check dependency security.

Review the final report and fix the important issues.

This is useful because security problems are not always inside the Laravel application.

Sometimes the application code is fine, but the development or deployment environment is configured incorrectly.

Moat is not a complete security scanner

One important thing I noticed is that Moat should not be treated as a complete security audit.

It checks GitHub configuration and provides recommendations.

It does not mean that a repository is automatically secure after all checks pass.

For example, it does not replace:

Laravel application security testing

Dependency auditing

Server security

Database security

API security testing

Code review

Penetration testing

Secret rotation

Infrastructure security

It is better to think of it as a GitHub security checklist that can be automated.

GitHub security is part of application security

As developers, we normally think about security in terms of application code.

For example:

$request->validate([
    'email' => ['required', 'email'],
    'password' => ['required'],
]);

We think about SQL injection, XSS, CSRF, authentication and authorization.

These are important.

But modern applications also depend heavily on GitHub and CI/CD.

A Laravel application may follow this flow:

Developer
   ↓
GitHub
   ↓
Pull Request
   ↓
GitHub Actions
   ↓
Tests
   ↓
Build
   ↓
Deployment
   ↓
Production Server

Every stage is part of the software delivery chain.

If one stage is poorly protected, the application can still be at risk.

My practical takeaway

I think repository security should become part of the normal development checklist, just like code review and automated testing.

For a small personal project, some enterprise-level controls may not be necessary.

But for a SaaS application, production application or open-source package, GitHub security deserves much more attention.

The main lesson for me is simple:

We should not secure only the Laravel application. We should also secure the system that builds and deploys the Laravel application.

Tools such as Moat make this easier by putting many GitHub security checks into one review instead of asking developers to manually search through many GitHub settings.

That makes repository security easier to include in a normal developer workflow.