Skip to main content

Linters and Local Security Validations

💡 Practical note:
Most modern languages and frameworks already have configurable linters and validators (such as ESLint, Pylint, RuboCop, etc.), many of which include basic security rules by default.
Tools such as Semgrep, SonarLint or IDEs such as VSCode and IntelliJ also allow custom policies to be applied.
Adopting them reinforces security even before the commit and prevents bad practices from spreading to the main repository.

📌 Objectives​

  • Ensure that common errors and bad practices are detected before code is submitted.
  • Increase the consistency and technical quality of the code produced.
  • Automate security validations, reducing exclusive reliance on human review.
  • Establish auditable minimum validation criteria before changes are integrated into the repository.

This document defines the minimum requirements for local validation and security linting that must be present in any active project.

Consistent application of these validations significantly reduces the introduction of trivial security errors and improves the traceability of fixes.

👥 Who should apply it​

  • All developers while writing code.
  • Technical leads when configuring the repository and pipelines.
  • PR reviewers, ensuring that the linters have been run and passed.

⏱️ When to apply it​

  • Before any commit or push.
  • When the PR is created (via hook or pipeline).
  • During technical reviews.
  • Periodically, as part of maintenance tasks.

🧱 Minimum requirements​

  1. Mandatory local execution of linters with minimum security rules

    • Must be part of the development flow
    • E.g. ESLint with the eslint-plugin-security plugin, Bandit for Python

  2. Validation integrated into the PR via CI/CD

    • The pipeline must block merges in the event of critical failures
    • Rules must be visible and justifiable

  3. Rules aligned with the internal secure coding guidelines

    • Linters must reinforce what is defined in addon/01-boas-praticas-codigo.md

  4. Versioned and auditable configuration

    • The .eslintrc, .pylintrc, .semgrep.yml files, etc., must be in the repository
    • Updates must be tracked and justified

🚨 Common flaws detectable with linters​

  • Use of eval, exec, innerHTML without escaping
  • Missing verification of mandatory parameters
  • Inclusion of dead code, sensitive comments or debugging
  • Instances of known vulnerabilities (by CWE) with autofix

✅ How to validate​

  • Local execution before the commit (pre-commit, make lint, etc.)
  • Automatic execution in build or PR pipelines
  • Presence of reports or logs in the PR
  • Integration with the IDE and visible alerts during development

🧾 How to evidence it​

  • Pipeline logs showing the linters being run
  • Screenshot or output integrated into the PR
  • Versioned linter configuration files
  • Validation mark in the PR template ([x] Linter executado e sem falhas)

🔄 Link to other practices​

ThemeAssociated file
Secure development guidelinesaddon/01-boas-praticas-codigo.md
Validations in the CI/CD pipelineaddon/08-validacoes-codigo.md
Justification of exceptionsaddon/05-excecoes-e-justificacoes.md
Annotation of validationsaddon/09-anotacoes-evidencia.md

📌 The absence of linting, or running it only optionally, is one of the clearest signs of low technical maturity and latent risk.
These practices must be mandatory, verified and auditable per project.