Repository: DependencyTrack/dependency-track

Issue #2366: Sudden failure to decrypt the OSS Index API Token
Created: 2023-01-10T13:56:12Z
Current Behavior
We're seeing something that resembles an expiration of the OSS Index API Token: after running without issues for a couple of days with our API Token (created at https://ossindex.sonatype.org/user/settings) , we suddenly see messages such as these in the logs:
2022-12-28 08:00:27,749 ERROR [OssIndexAnalysisTask] An error occurred decrypting the OSS Index API Token. Skipping javax.crypto.BadPaddingException: Given final block not properly padded. Such issues can arise if a bad key is used during decryption. at java.base/com.sun.crypto.provider.CipherCore.unpad(Unknown Source) at java.base/com.sun.crypto.provider.CipherCore.fillOutputBuffer(Unknown Source) at java.base/com.sun.crypto.provider.CipherCore.doFinal(Unknown Source) at java.base/com.sun.crypto.provider.AESCipher.engineDoFinal(Unknown Source) at java.base/javax.crypto.Cipher.doFinal(Unknown Source) at alpine.security.crypto.DataEncryption.decryptAsBytes(DataEncryption.java:136) at alpine.security.crypto.DataEncryption.decryptAsBytes(DataEncryption.java:148) at alpine.security.crypto.DataEncryption.decryptAsString(DataEncryption.java:176) at org.dependencytrack.tasks.scanners.OssIndexAnalysisTask.inform(OssIndexAnalysisTask.java:138) at org.dependencytrack.tasks.VulnerabilityAnalysisTask.performAnalysis(VulnerabilityAnalysisTask.java:169) at org.dependencytrack.tasks.VulnerabilityAnalysisTask.analyzeComponents(VulnerabilityAnalysisTask.java:128) at org.dependencytrack.tasks.VulnerabilityAnalysisTask.inform(VulnerabilityAnalysisTask.java:77) at alpine.event.framework.BaseEventService.lambda$publish$0(BaseEventService.java:101) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) 
When this happens no new (OSS Index fed) vulnerabilities are detected until we create a new API token and and set it in /admin -> Analyzers -> Sonatype OSS Index
Steps to Reproduce

Create an API Token at https://ossindex.sonatype.org/user/settings
Enter the API token in /admin -> Analyzers -> Sonatype OSS Index
Let DTrack run for a while (a week or two) while you upload SBOMs
Check the logs

Expected Behavior
The OSS Index API Token never "expires"
Dependency-Track Version
4.7.0
Dependency-Track Distribution
Container Image
Database Server
PostgreSQL
Database Server Version
13.7
Browser
N/A
Checklist

 I have read and understand the contributing guidelines
 I have checked the existing issues for whether this defect was already reported

Duplicate issue #4260: Trivy analyzer fails on container restart.
Created: 2024-10-15T12:33:33Z
Current Behavior
I am running my Trivy container in a sidecar with the following command:
args   = ["server", "--listen", "0.0.0.0:8081", "--token", "plaintext", "--cache-backend", "memory"]

I have the following Trivy config (plaintext written as API token here):

When I restart my dependency-track backend container & therefore Trivy sidecar. Requests to Trivy analyzer fail with the following error:
javax.crypto.BadPaddingException: Given final block not properly padded. Such issues can arise if a bad key is used during decryption.
	at java.base/com.sun.crypto.provider.CipherCore.unpad(Unknown Source)
	at java.base/com.sun.crypto.provider.CipherCore.fillOutputBuffer(Unknown Source)
	at java.base/com.sun.crypto.provider.CipherCore.doFinal(Unknown Source)
	at java.base/com.sun.crypto.provider.AESCipher.engineDoFinal(Unknown Source)
	at java.base/javax.crypto.Cipher.doFinal(Unknown Source)
	at alpine.security.crypto.DataEncryption.decryptAsBytes(DataEncryption.java:136)
	at alpine.security.crypto.DataEncryption.decryptAsBytes(DataEncryption.java:148)
	at alpine.security.crypto.DataEncryption.decryptAsString(DataEncryption.java:176)
	at org.dependencytrack.util.DebugDataEncryption.retryDecryptAsString(DebugDataEncryption.java:59)
	at org.dependencytrack.util.DebugDataEncryption.decryptAsString(DebugDataEncryption.java:54)
	at org.dependencytrack.tasks.scanners.TrivyAnalysisTask.inform(TrivyAnalysisTask.java:150)
	at org.dependencytrack.tasks.VulnerabilityAnalysisTask.performAnalysis(VulnerabilityAnalysisTask.java:197)
	at org.dependencytrack.tasks.VulnerabilityAnalysisTask.analyzeComponents(VulnerabilityAnalysisTask.java:157)
	at org.dependencytrack.tasks.VulnerabilityAnalysisTask.inform(VulnerabilityAnalysisTask.java:87)
	at alpine.event.framework.BaseEventService.lambda$publish$0(BaseEventService.java:110)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.base/java.lang.Thread.run(Unknown Source)

For Trivy to work, I need to:

Know that my container has restarted
Go to Trivy config in UI and rewrite plaintext as trivy api token (even though it should already be plaintext from my last time I wrote it there)

Retries aren't working. It can stay broken like this for multiple weeks without you noticing unless you have an alert on error logs.
Also --cache-backend memory should be mentioned in Trivy docs for scenarios where you don't have a volume at hand for your Trivy container.
Proposed Behavior
When I restart my container, Trivy keeps working without manual intervention.
Checklist

 I have read and understand the contributing guidelines
 I have checked the existing issues for whether this enhancement was already requested

Closing comment (2024-11-05T11:40:24Z): Duplicate of #2366.
If this happens on every restart, please verify that you're mounting the /data directory to a persistent volume, and that files in that volume are accessible by the restarted instance (randomized user IDs can cause issues here).
The key used to encrypt and decrypt secrets is stored on disk. If that is not persisted, DT will generate a new key on startup that of course won't work with secrets already stored in the DB.