Improve our security practices, in particular around binary files

### What is the problem this feature will solve?

Recent malicious supply chain attacks have seen binary files slipped into a package (as test files in that case) that served as an attack vector. Could this happen to astropy? How do we prevent it?

### Describe the desired outcome

Not clear. This issue is to collect ideas how to address the problem, for example:

- Be weary of binary files (e.g. compressed files). We don’t have many though, but we want to be careful where we have them.
- For every binary file, we should ask for the script that generates that binary data.
- Auto detect in PR and ping security team?
- We don’t control tests with remote-data. That gets pulled from URLs that could (in principle) have everything. Waht do we do?

### Additional context

Automated tools for some security checks exist, e.g.
- https://github.com/slsa-framework/slsa-github-generator
- https://scorecard.dev/

Infrastructure of security team should run those, see what the results are, fix what’s easy to fix and write down examples where general checks do not apply to astropy (and thus give bad marks).
Goal would be to run those checks in CI for people to look at and decide themselves how useful it is.

Start by reviewing the SLSA GitHub generator and Scorecard checks named in the issue, then examine how security-team checks could run in astropy’s CI. Done means useful checks run in CI, easy findings are addressed, and examples of checks that do not apply—especially binary files and remote test data—are documented.

Written by the indexing model from the issue text.