Check for and update outdated integrations

[crysmags]

What does this PR do?

This PR is a continuation of @bengl PR check for outdated integrations. This will check for the latest versions of the integrations and update them in a JSON file called latest.json, if any versions have been updated a PR will then be created in the event there is not a current branch or PR.

[datadog-datadog-prod-us1]

🟠 Code Vulnerability

No explicit permissions set for at the workflow level (...read more)

Check the permissions granted to jobs

Datadog’s GitHub organization defines default permissions for the GITHUB_TOKEN to be restricted (contents:read, metadata:read and packages:read).

Your repository may require different setup, but please consider defining permissions for each job following the least privilege principle to restrict the impact of a possible compromission.

You can find the list of all possible permissions in Workflow syntax for GitHub Actions - GitHub Docs. Please note they can be defined at the job or the workflow level.

    

[datadog-datadog-prod-us1]

🟠 Code Vulnerability

Workflow depends on a GitHub actions pinned by tag (...read more)

Pin third party actions by hash, or at least by tag for trusted sources

When using a third party action, one needs to provide its GitHub path (owner/project) and can eventually pin it to a git ref (a branch name, a git tag, or a commit hash).

No pinned git ref means the action will use the latest commit of the default branch each time it runs, eventually running newer versions of the code that were not audited by Datadog. Specifying a git tag is better, but since they are not immutable, using a full length hash is recommended to make sure the action content is actually frozen to some reviewed state.

Be careful however, as even pinning an action by hash can be circumvented by attackers still. For instance, if an action relies on a Docker image which is itself not pinned to a digest, it becomes possible to alter its behaviour through the Docker image without actually changing its hash. You can learn more about this kind of attacks in Unpinnable Actions: How Malicious Code Can Sneak into Your GitHub Actions Workflows. Pinning actions by hash is still a good first line of defense against supply chain attacks.

Additionally, pinning by hash or tag means the action won’t benefit from newer version updates if any, including eventual security patches. Make sure to regularly check if newer versions for an action you use are available. For actions coming from a very trustworthy source, it can make sense to use a laxer pinning policy to benefit from updates as soon as possible.

    

[datadog-datadog-prod-us1]

🟠 Code Vulnerability

No explicit permissions set for at the workflow level (...read more)

Check the permissions granted to jobs

Datadog’s GitHub organization defines default permissions for the GITHUB_TOKEN to be restricted (contents:read, metadata:read and packages:read).

Your repository may require different setup, but please consider defining permissions for each job following the least privilege principle to restrict the impact of a possible compromission.

You can find the list of all possible permissions in Workflow syntax for GitHub Actions - GitHub Docs. Please note they can be defined at the job or the workflow level.

    

[datadog-datadog-prod-us1]

🟠 Code Vulnerability

Workflow depends on a GitHub actions pinned by tag (...read more)

Pin third party actions by hash, or at least by tag for trusted sources

When using a third party action, one needs to provide its GitHub path (owner/project) and can eventually pin it to a git ref (a branch name, a git tag, or a commit hash).

No pinned git ref means the action will use the latest commit of the default branch each time it runs, eventually running newer versions of the code that were not audited by Datadog. Specifying a git tag is better, but since they are not immutable, using a full length hash is recommended to make sure the action content is actually frozen to some reviewed state.

Be careful however, as even pinning an action by hash can be circumvented by attackers still. For instance, if an action relies on a Docker image which is itself not pinned to a digest, it becomes possible to alter its behaviour through the Docker image without actually changing its hash. You can learn more about this kind of attacks in Unpinnable Actions: How Malicious Code Can Sneak into Your GitHub Actions Workflows. Pinning actions by hash is still a good first line of defense against supply chain attacks.

Additionally, pinning by hash or tag means the action won’t benefit from newer version updates if any, including eventual security patches. Make sure to regularly check if newer versions for an action you use are available. For actions coming from a very trustworthy source, it can make sense to use a laxer pinning policy to benefit from updates as soon as possible.

    

[github-actions]

Overall package size

Self size: 7.64 MB
Deduped: 62.87 MB
No deduping: 63.21 MB

Dependency sizes

| name | version | self size | total size | |------|---------|-----------|------------| | @datadog/native-appsec | 8.2.1 | 19.18 MB | 19.19 MB | | @datadog/native-iast-taint-tracking | 3.1.0 | 12.27 MB | 12.28 MB | | @datadog/pprof | 5.4.1 | 9.76 MB | 10.13 MB | | protobufjs | 7.2.5 | 2.77 MB | 5.16 MB | | @datadog/native-iast-rewriter | 2.5.0 | 2.51 MB | 2.65 MB | | @opentelemetry/core | 1.14.0 | 872.87 kB | 1.47 MB | | @datadog/native-metrics | 2.0.0 | 898.77 kB | 1.3 MB | | @opentelemetry/api | 1.8.0 | 1.21 MB | 1.21 MB | | import-in-the-middle | 1.11.2 | 112.74 kB | 826.22 kB | | msgpack-lite | 0.1.26 | 201.16 kB | 281.59 kB | | opentracing | 0.14.7 | 194.81 kB | 194.81 kB | | lru-cache | 7.18.3 | 133.92 kB | 133.92 kB | | pprof-format | 2.1.0 | 111.69 kB | 111.69 kB | | @datadog/sketches-js | 2.1.0 | 109.9 kB | 109.9 kB | | semver | 7.6.3 | 95.82 kB | 95.82 kB | | lodash.sortby | 4.7.0 | 75.76 kB | 75.76 kB | | ignore | 5.3.1 | 51.46 kB | 51.46 kB | | int64-buffer | 0.1.10 | 49.18 kB | 49.18 kB | | shell-quote | 1.8.1 | 44.96 kB | 44.96 kB | | istanbul-lib-coverage | 3.2.0 | 29.34 kB | 29.34 kB | | rfdc | 1.3.1 | 25.21 kB | 25.21 kB | | tlhunter-sorted-set | 0.1.0 | 24.94 kB | 24.94 kB | | limiter | 1.1.5 | 23.17 kB | 23.17 kB | | dc-polyfill | 0.1.4 | 23.1 kB | 23.1 kB | | retry | 0.13.1 | 18.85 kB | 18.85 kB | | jest-docblock | 29.7.0 | 8.99 kB | 12.76 kB | | crypto-randomuuid | 1.0.0 | 11.18 kB | 11.18 kB | | koalas | 1.0.2 | 6.47 kB | 6.47 kB | | path-to-regexp | 0.1.10 | 6.38 kB | 6.38 kB | | module-details-from-path | 1.0.3 | 4.47 kB | 4.47 kB |

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

[pr-commenter]

Benchmarks

Benchmark execution time: 2024-10-24 18:15:27

Comparing candidate commit 4b6a133 in PR branch crysmags/outdated-integrations with baseline commit fcecd86 in branch master.

Found 22 performance improvements and 0 performance regressions! Performance is the same for 236 metrics, 8 unstable metrics.

scenario:appsec-iast-no-vulnerability-control-18

• 🟩 cpu_user_time [-123.864ms; -101.944ms] or [-20.309%; -16.715%]
• 🟩 execution_time [-119.371ms; -92.361ms] or [-15.220%; -11.776%]
• 🟩 instructions [-192.9M instructions; -190.4M instructions] or [-13.109%; -12.938%]
• 🟩 max_rss_usage [-7.135MB; -6.535MB] or [-8.556%; -7.837%]

scenario:appsec-iast-no-vulnerability-iast-enabled-always-active-18

• 🟩 cpu_user_time [-127.875ms; -91.162ms] or [-9.786%; -6.976%]
• 🟩 execution_time [-168.344ms; -81.177ms] or [-11.073%; -5.339%]
• 🟩 instructions [-214.0M instructions; -203.8M instructions] or [-8.182%; -7.790%]

scenario:appsec-iast-no-vulnerability-iast-enabled-default-config-18

• 🟩 cpu_user_time [-131.291ms; -100.669ms] or [-10.373%; -7.954%]
• 🟩 execution_time [-173.423ms; -87.712ms] or [-11.629%; -5.882%]
• 🟩 instructions [-205.2M instructions; -189.1M instructions] or [-8.399%; -7.738%]

scenario:appsec-iast-with-vulnerability-control-18

• 🟩 cpu_user_time [-120.496ms; -84.989ms] or [-12.621%; -8.902%]
• 🟩 execution_time [-184.559ms; -100.814ms] or [-12.607%; -6.886%]
• 🟩 instructions [-227.2M instructions; -214.8M instructions] or [-9.016%; -8.524%]

scenario:appsec-iast-with-vulnerability-iast-enabled-always-active-18

• 🟩 cpu_user_time [-144.520ms; -94.016ms] or [-8.065%; -5.246%]
• 🟩 instructions [-318.2M instructions; -285.5M instructions] or [-7.353%; -6.599%]

scenario:appsec-iast-with-vulnerability-iast-enabled-default-config-18

• 🟩 cpu_user_time [-202.005ms; -146.249ms] or [-11.791%; -8.536%]
• 🟩 execution_time [-305.080ms; -143.979ms] or [-12.381%; -5.843%]
• 🟩 instructions [-296.1M instructions; -250.9M instructions] or [-7.616%; -6.455%]

scenario:plugin-q-with-tracer-18

• 🟩 cpu_user_time [-137.402ms; -120.631ms] or [-14.788%; -12.983%]
• 🟩 execution_time [-143.028ms; -129.820ms] or [-13.875%; -12.593%]
• 🟩 instructions [-211.7M instructions; -200.7M instructions] or [-11.945%; -11.325%]
• 🟩 max_rss_usage [-8.546MB; -8.150MB] or [-5.625%; -5.365%]

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 62.88%. Comparing base (bb0bbcc) to head (f258d81).
Report is 11 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff             @@
##           master    #4694       +/-   ##
===========================================
- Coverage   91.42%   62.88%   -28.54%     
===========================================
  Files         112      130       +18     
  Lines        3475     4567     +1092     
  Branches       33       33               
===========================================
- Hits         3177     2872      -305     
- Misses        298     1695     +1397     

Flag	Coverage Δ
	62.88% <ø> (-28.54%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

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