Skip to content

Spectral OWASP linting rules#95

Draft
rartych wants to merge 20 commits intocamaraproject:mainfrom
rartych:extend_spectral_owasp
Draft

Spectral OWASP linting rules#95
rartych wants to merge 20 commits intocamaraproject:mainfrom
rartych:extend_spectral_owasp

Conversation

@rartych
Copy link
Contributor

@rartych rartych commented Feb 27, 2026

What type of PR is this?

  • enhancement/feature

What this PR does / why we need it:

This PR adds Spectral OWASP linting rules to be used in reusable linting workflows.

  • .spectral-owasp.yaml includes OWASP rules selected in https://github.com/camaraproject/Commonalities/blob/main/documentation/Linting-rules.md
  • .spectral-owasp-target.yaml modifies severity of api4 rules to target values
  • .spectral-camara.yaml aggregates rulesests (already defined and OWASP) as Megalinter requires only one input parameter for ruleset file
  • spectral-oas.yml - refactored workflow for manually launched Spectral linting (including OWASP target ruleset)
  • pr_validation.yml - changed ruleset file to .spectral-camara.yaml

Which issue(s) this PR fixes:

Fixes #

Special notes for reviewers:

Changelog input

Spectral OWASP linting rules added to reusable linting workflows

Additional documentation

@rartych rartych requested a review from Kevsy as a code owner February 27, 2026 12:55
@Kevsy
Copy link
Contributor

Kevsy commented Mar 2, 2026

@rartych looks good, but why are so many rules excluded (off) by default - was that the outcome of earlier discussions?

@rartych
Copy link
Contributor Author

rartych commented Mar 2, 2026

why are so many rules excluded (off) by default - was that the outcome of earlier discussions?

Yes I tried to review all the rules in camaraproject/Commonalities#539 and its sub-issues.
The reasons to exclude some rules are:

  • CAMARA APIs use advanced Auth schemes (defined by ICM) - not covered in the rules
  • some security features are not specified in CAMARA and left to implementation/API Gateway configuration (rate limiting, intended environment in server descriptions using terms like local, staging, production)
  • some rules are for OAS 3.1 (they OAS 3.0 counterparts named as -legacy are active)

Of course the selection can be modified if needed.
Other question is: If CAMARA specific rules for OWASP recommendations can be added beyond the official Spectral ruleset?

@Kevsy
Copy link
Contributor

Kevsy commented Mar 2, 2026

Yes I tried to review all the rules in camaraproject/Commonalities#539 and its sub-issues.

Thanks, I suspected that was the case - but good to confirm.

Other question is: If CAMARA specific rules for OWASP recommendations can be added beyond the official Spectral ruleset?

I believe that should be allowed. If they are rules for existing OWASP recommendations, they could be including in the *owasp*yaml files, if they are complementary security rules they could be included in spectral-camara.yaml

@hdamker
Copy link
Contributor

hdamker commented Mar 20, 2026

Parking this for now. The rule selection and review work by @rartych and @Kevsy is valuable and will feed directly into the Validation Framework v1 ruleset. The reason for parking: pr_validation v0 cannot differentiate between Commonalities versions, so enabling OWASP rules that depend on r4.x schema constraints would produce false positives on repositories still on r3.4. The v1 design (ReleaseManagement#447) addresses this with version-aware ruleset selection (section 7.5).

@hdamker
Copy link
Contributor

hdamker commented Mar 20, 2026

Converted to draft — see parking rationale.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants