fix(ci): make sure dependabot is secure and able to update everthing

[BridgeAR]

• Use synchronize to fix running the dependabot on updates to the branch
• Separate the vendoring into two steps. One for installing and vendoring with read permissions only. The other for pushing with write permissions.
  This is safer, since it does not allow the install step to push to the branch.

[github-actions]

Overall package size

Self size: 4.42 MB
Deduped: 5.24 MB
No deduping: 5.24 MB

Dependency sizes

| name | version | self size | total size | |------|---------|-----------|------------| | import-in-the-middle | 2.0.0 | 68.46 kB | 797.03 kB | | dc-polyfill | 0.1.10 | 26.73 kB | 26.73 kB |

_{🤖 This report was automatically generated by heaviest-objects-in-the-universe}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.26%. Comparing base (3f41eb1) to head (88e1340).
⚠️ Report is 19 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #7241   +/-   ##
=======================================
  Coverage   86.26%   86.26%           
=======================================
  Files         513      513           
  Lines       22067    22067           
=======================================
  Hits        19035    19035           
  Misses       3032     3032           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[pr-commenter]

Benchmarks

Benchmark execution time: 2026-01-20 09:56:07

Comparing candidate commit 88e1340 in PR branch BridgeAR/2026-01-14-fix-dependabot-ci-job with baseline commit 3f41eb1 in branch master.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 229 metrics, 31 unstable metrics.

[rochdev]

Let's get the security team to look at it since we use pull_request_target in combination with actions/checkout.

[rochdev]

@BridgeAR Can you add a PR description? Reading through the PR it seems like a pretty big and complicated addition and it's unclear why it's needed at all.

[BridgeAR]

@rochdev done

[rochdev]

Separate the vendoring into two steps. One for installing and vendoring with read permissions only. The other for pushing with write permissions. This is safer, since it does not allow the install step to push to the branch.

In what way is it safer? With the current setup, any bad actor would be able to just change the workflow so the contents of the individual jobs doesn't really matter, what matters is the Octo STS claims.

I'm a bit worried about adding so much untestable shell scripting if there isn't a strong argument for, so let's make that argument clear 😄

[KSerrania]

In what way is it safer? With the current setup, any bad actor would be able to just change the workflow so the contents of the individual jobs doesn't really matter, what matters is the Octo STS claims.

The main idea behind separating steps is not to protect against someone already able to write to the repository.- in this case, they do not need to go through such lengths to get contents: write and pull-requests: write access, since they already have it.

The goal is to prevent malicious code that could run as part of the vendoring scripts (e.g. if it ends up being vulnerable to arbitrary code execution) from being able to get access to valuable credentials (write access to the repository).

Giving as few steps as possible sensitive access within a workflow limits this risk, which contributes to improving the security of the repository. However, security is about trade-offs - here, between keeping these scripts maintainable and reducing the access they may provide. If you deem this approach harmful to the maintainability of your repository, we can try to think about alternative ways to secure the repository.