feat(helm-chart): ensure unique resource names (#11) #2
Annotations
10 warnings
KICS scan:
charts/policy-hub/templates/deployment-hub.yaml#L1
CPU limits should be set because if the system has CPU time free, a container is guaranteed to be allocated as much CPU as it requests
|
KICS scan:
charts/policy-hub/templates/deployment-hub.yaml#L36
Check if containers are running with low UID, which might cause conflicts with the host's user table.
|
KICS scan:
charts/policy-hub/templates/deployment-hub.yaml#L1
Memory limits should be defined for each container. This prevents potential resource exhaustion by ensuring that containers consume not more than the designated amount of memory
|
KICS scan:
charts/policy-hub/templates/deployment-hub.yaml#L1
Containers should be configured with a secure Seccomp profile to restrict potentially dangerous syscalls
|
KICS scan:
charts/policy-hub/templates/deployment-hub.yaml#L1
Service Account Tokens are automatically mounted even if not necessary
|
KICS scan:
.github/workflows/trivy-dev.yml#L67
Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload. When selecting a SHA, you should verify it is from the action's repository and not a repository fork.
|
KICS scan:
.github/workflows/trivy-dev.yml#L133
Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload. When selecting a SHA, you should verify it is from the action's repository and not a repository fork.
|
KICS scan:
.github/workflows/trivy-dev.yml#L100
Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload. When selecting a SHA, you should verify it is from the action's repository and not a repository fork.
|
KICS scan:
.github/workflows/release_candidate.yml#L97
Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload. When selecting a SHA, you should verify it is from the action's repository and not a repository fork.
|
KICS scan:
.github/workflows/release_candidate.yml#L106
Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload. When selecting a SHA, you should verify it is from the action's repository and not a repository fork.
|
The logs for this run have expired and are no longer available.
Loading