The script reads a local .env file to load configuration, which is a standard and expected pattern for a standalone Node process.
Technical evidence
Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment. The match applies to this repository.
Contextual assessment: The signal at line 34 corresponds to a minimal dotenv loader that parses a local .env file and sets process.env entries only when the key is not already present. This is a conventional configuration-loading pattern with no network transmission of the parsed values at this point. The loaded values (port, base URL, API key, debug flag) are used solely for the bridge's stated purpose.
Credential access and network transmission in one file
Expected behavior · high confidence
The bridge's entire job is to take the shodh API key and attach it to requests forwarded to the shodh memory server. The key is sent only to the user's own shodh server, which is the expected behavior.
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 process.env (line 44) and includes it as an X-API-Key header in fetch calls (line 66) to SHODH_BASE_URL (default localhost:3030). This is the bridge's stated, documented purpose: it sits between Marinara's webhook tools and shodh-memory, injecting the API key that Marinara's webhook format cannot carry. The credential flows only to the user-configured shodh endpoint. No third-party or unexpected destination is present. Debug logging does not emit the API key or headers.
The bridge reads the shodh API key from environment variables and includes it in requests sent to the shodh memory server. This is exactly what the bridge was built to do, and the key goes only to the user-configured shodh server address.
Technical evidence
Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.credential-to-network. The match applies to this repository.
Contextual assessment: The SHODH_API_KEY is read from process.env (line 44) and sent as an X-API-Key header (line 66) in fetch calls to SHODH_BASE_URL, which defaults to localhost:3030. This is the explicit, documented purpose of the bridge: Marinara's webhook tools cannot add custom auth headers, so the bridge injects the API key before forwarding to shodh's REST API. The credential destination is the user-configured shodh server, not any third-party or hardcoded external endpoint. No other network sinks exist in the file. Debug logging (line 59) logs URL and body but does not log headers or the API key.
This line simply reads a port number from configuration. There is no suspicious link or network activity.
Technical evidence
Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.shady-link. The match applies to this repository.
Contextual assessment: Line 42 reads BRIDGE_PORT from process.env with a default of 8135. This is benign configuration handling with no URL, link, or network sink. The scanner signal appears to be a false positive.
The API key is sent to the shodh memory server as an authentication header. This is the bridge's core function and the destination is the user's own local shodh server, not any external service.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.credential-exfiltration.javascript-secret-to-network. The match applies to this repository.
Contextual assessment: Lines 64-69 show a fetch call to SHODH_BASE_URL with the X-API-Key header set to SHODH_API_KEY. The base URL is user-configured and defaults to localhost:3030. The bridge's README and inline comments explicitly describe this exact behavior: unwrap Marinara's webhook payload, inject the API key header, and forward to shodh's REST API. The credential-to-network path is intentional, proportionate, and disclosed. There is no exfiltration to an unexpected destination, no obfuscation, and no secondary network sink.