Allow enabling secret and code scanning

[raboof]

It looks like these options are off by default and cannot be enabled self-service.

It might be good to consider allowing projects to enable them, and perhaps even enable them by default

[ppkarwasz]

Sounds good to me!

For Secret Protection (secret scanning + push protection), I'd suggest enabling it by default at the organization level, with push protection bypass disabled.

For Code scanning, this could be driven from .asf.yaml and applied via PATCH /repos/{owner}/{repo}/code-scanning/default-setup, e.g.:

github:
  code_scanning:
    # One of: "default" (faster, fewer false positives)
    #     or: "extended" (more queries, broader coverage)
    query_suite: default

    # One of: "remote" (default, attacker is external)
    #     or: "remote_and_local" (also models local attackers,
    #         e.g. malicious files on disk or untrusted env vars)
    threat_model: remote

    # CodeQL-supported languages to analyze. Allowed values:
    #   actions, c-cpp, csharp, go, java-kotlin,
    #   javascript-typescript, python, ruby, rust, swift
    languages:
      - actions
      - java-kotlin

Behavior I'd propose:

• If the code_scanning block is present, sync the repo's default setup to match (state configured, plus the specified languages and query suite).
• If the block is absent, set the state body parameter to not-configured, which will allow maintainers to set up their own CodeQL workflow.

[potiuk]

For Secret Protection (secret scanning + push protection), I'd suggest enabling it by default at the organization level, with push protection bypass disabled.

Agree.

If the block is absent, set the state body parameter to not-configured, which will allow maintainers to set up their own CodeQL workflow.

Not sure I follow ?

[ppkarwasz]

Unless I am mistaken the default behavior of ASFYaml features is:

• If an element is present (e.g. code_scanning), process it,
• Otherwise do nothing.

The second case is problematic: if users remove the code_scanning element, code scanning will be still configured in the same way as it was before. This problem touches many other features (e.g. branch_protection: if you remove it, it will be still there).

[potiuk]

The second case is problematic: if users remove the code_scanning element, code scanning will be still configured in the same way as it was before. This problem touches many other features (e.g. branch_protection: if you remove it, it will be still there).

Yeah I think it was deliberate choice by the team @Humbedooh ?