No material or high-risk concern was identified in this review.
This advisory report describes what the named tools and contextual reviewer found at one exact commit. Unknown or unobserved behavior may still exist.
0 high0 material2 low
What this review found
No material or high-risk item was identified.
Expected scanner matches (2)
Credential access and network transmission in one file
Expected behavior · high confidence
This bridge script reads an API key from a local configuration file and sends it to the memory service it is supposed to talk to. That is exactly what the project says it does and why the bridge exists. The key goes to a service the user themselves runs and configures, not to any outside party.
Technical evidence
Scanner reason: A credential source and an outbound network operation were detected in the same file.
Contextual assessment: The file reads SHODH_API_KEY from a local .env file or process environment and transmits it as an X-API-Key header to SHODH_BASE_URL, which defaults to localhost:3030 and is user-configured. This is the explicitly stated purpose of the bridge: Marinara webhook tools cannot add custom headers, so the bridge injects the API key and forwards to the shodh-memory REST API. The credential destination is the intended backend service, not a third party. No obfuscation, no hardcoded external endpoint, no concealed exfiltration path.
The scanner flagged that an API key and a network call appear together. Looking at the actual code, the key is sent only to the local memory service the user configured, which is the whole point of this bridge tool. The key itself is never logged or sent to any other destination.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.credential-exfiltration.javascript-secret-to-network in this repository.
Contextual assessment: The scanner matched because an environment-sourced secret reaches a network sink in the same file. Examining the data flow: SHODH_API_KEY is loaded from a local .env or process env, then placed in the X-API-Key header of a POST to SHODH_BASE_URL (default localhost:3030, user-configurable). The destination is the shodh-memory backend that the bridge is designed to proxy for. The README explains this exact mechanism as the reason the bridge exists. There is no indication the key is sent anywhere other than the user's own configured shodh instance, nor is it logged (only URL and body are logged in debug mode, not the key).