How do we want to handle code auditing now that Rails ships with a solution?

[stevepolitodesign]

Rails 7.2 now ships with brakeman.

However, with the introduction of #1138, we risk having two auditing mechanisms.

[stevepolitodesign]

One solution could be to simply skip this option.

https://github.com/rails/rails/blob/ff0ef93e28d4919ffd8bf130132b7b7e3435c67a/railties/lib/rails/generators/app_base.rb#L105

[stevepolitodesign]

Alternatively, we keep it, and just make sure CI runs the command. Below is from a fresh Rails 8 install.

jobs:
  scan_ruby:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Ruby
        uses: ruby/setup-ruby@v1
        with:
          ruby-version: .ruby-version
          bundler-cache: true

      - name: Scan for common Rails security vulnerabilities using static analysis
        run: bin/brakeman --no-pager

[nickcharlton]

I do quite like running this sort of thing on CI, so long as it's also available locally so that if you've got a problem you're debugging the feedback cycle is much tighter.

I feel like it's a case of automating the things I would otherwise forget, or that locally might break. I want linting on CI as well as in my editor, for example.