Consider pinning CI dependencies more strictly

Currently, this is possible:

1. CI passes on a PR
2. We merge the PR
3. CI fails on `main`

I suggest that we should minimize the possibility of this because:

- CI should always be passing on `main`
- PRs are harder to review when there are unrelated CI failures
- It causes a context switch - CI should be fixed before other PRs can be merged

Recently, for example, CI passed on PR https://github.com/crashappsec/chalk/pull/135 but then failed on `main` with https://github.com/crashappsec/chalk/commit/f496958f9e3078f7f52b5e84bfdce5847dee6f26. @miki725 says it's because a new version of semgrep was released. This also caused CI to fail in PR https://github.com/crashappsec/chalk/pull/137.

In this case, can we pin the versions of dependencies like semgrep, and have automated PRs to update them?

Alternatively, the problem is alleviated somewhat if we use a merge queue.