Gitlab CI docs

This is for the docs.

I was previously using the Sensiolabs security service in GitLab CI with a script like this:

 script:
    - test -d security-checker || git clone https://github.com/sensiolabs/security-checker.git
    - cd security-checker
    - composer install
    - php security-checker security:check ../composer.lock

Since that service no longer operates, I have changed it to use this new local checker like this:

script:
    - curl -L -sS --output local-php-security-checker https://github.com/fabpot/local-php-security-checker/releases/download/v1.0.0/local-php-security-checker_1.0.0_linux_amd64
    - chmod +x ./local-php-security-checker
    - ./local-php-security-checker

This works fine for now, but I'd really like to see a simple way of abstracting the version and the OS target so that CI systems using it work more easily across platforms and require fewer changes when updates are released, as the old system effectively did.

Maybe this may help a little:

to link directly to a download of your latest release asset, link to /owner/name/releases/latest/download/asset-name.zip.
https://docs.github.com/en/github/administering-a-repository/linking-to-releases

Good catch, however, I think it only gets us halfway. The version number appears twice in the URL, once in the path, but it's also in the filename, so as far as I can see that "latest release" abstraction doesn't fix that. I think we'd end up with:

https://github.com/fabpot/local-php-security-checker/releases/latest/local-php-security-checker_1.0.0_linux_amd64

which doesn't work. You can't drop the version number either:

https://github.com/fabpot/local-php-security-checker/releases/latest/local-php-security-checker_linux_amd6
https://github.com/fabpot/local-php-security-checker/releases/latest/local-php-security-checker_linux_amd6.zip

Did I just get these wrong?

You could get the checksums.txt and there look for the line containing your OS architecture, then you have the current file name.

Unfortunately that's pretty much the opposite of a neat abstraction!
I guess a good solution would be to generate non-versioned copies of the same files that could somehow be pointed at. That wouldn't work with GitHub's latest pointer though. Annoyingly tricky!

Not the neatest way at all, but it works well.

# Installing PHP Security Checker
PHP_SC_VERSION=$(curl -s "https://api.github.com/repos/fabpot/local-php-security-checker/releases/latest" |
  grep '"tag_name":' |
  sed -E 's/.*"([^"]+)".*/\1/;s/^v//')
curl -LSs https://github.com/fabpot/local-php-security-checker/releases/download/v${PHP_SC_VERSION}/local-php-security-checker_${PHP_SC_VERSION}_linux_amd64 >/usr/local/bin/local-php-security-checker
chmod +x /usr/local/bin/local-php-security-checker
unset PHP_SC_VERSION

Combining @Synchro and @Pezhvak 's scripts, this is what it looks like for me:

  script:
    - PHP_SC_VERSION=$(curl -s "https://api.github.com/repos/fabpot/local-php-security-checker/releases/latest" | grep '"tag_name":' | sed -E 's/.*"([^"]+)".*/\1/;s/^v//')
    - curl -LSs https://github.com/fabpot/local-php-security-checker/releases/download/v${PHP_SC_VERSION}/local-php-security-checker_${PHP_SC_VERSION}_linux_amd64 > ./php-security-checker
    - chmod +x ./php-security-checker
    - unset PHP_SC_VERSION
    - ./php-security-checker

What are the advantages of always using the latest version? I don't see any, I would rather have considered that with a new defective version my environment variables will be transferred "somewhere" in the pipeline process

One always hopes that new versions have fewer bugs than older ones...

What are the advantages of always using the latest version? I don't see any, I would rather have considered that with a new defective version my environment variables will be transferred "somewhere" in the pipeline process

Are you really asking why we are developing? 😆

What are the advantages of always using the latest version? I don't see any, I would rather have considered that with a new defective version my environment variables will be transferred "somewhere" in the pipeline process

Are you really asking why are we developing? 😆

No, I didn't ask that at all.

I want to say that when you deal with the topic of security, you quickly get to the point that you shouldn't trust anyone. When I have a Gitlab pipeline running, which always uses the latest version of something automatically. How do you find out that the maintainer of a third-party library has changed and that the maintainer has only good intentions?

Don't you think that's it's more likely that not updating would expose you to known bugs & vulnerabilities that have been fixed in later versions? Exposure to known issues is a far bigger security problem than 0days.

I think it's more likely that something unpredictable will happen if you're always using the latest version. Let's say it depends. I'll do an update too, of course, but not immediately.

A package that installs the latest stable version of local-php-security-checker in the project's bin-dir is available on packagist:

composer require --dev thibautselingue/local-php-security-checker-installer

That's a good solution, thanks @cprn.