Security Findings
Security Findings
config/config.json:10-12stores the dashboard admin username/password in plaintext inside the repo, which makes the dashboard trivially accessible if the repository is compromised or shared. Move those credentials out of source control (load them from environment variables or a vault) and enforce per-deployment secrets with rotation..env:1commits the Telegram bot token (CRYSTAL_AGENTS_BOT_TOKEN), and although.gitignorelists.env, it is already tracked. Remove the file from git, rotate the token immediately, and ensure secrets live only in protected runtime config (e.g.,.env.template+ deployment secrets) so future pushes can’t leak them.deploy.sh:9-21enablesgit config --global credential.helper store, which writes GitHub PATs/credentials in cleartext under the invoking user’s home directory. That makes any future process on the host able to read the token; switch to a credential manager/cache that encrypts or periodically prompts, or require manualGIT_ASKPASS, and scope the PAT to the minimum required rights.scripts/qreport_scheduler.sh:15-27callssshwithStrictHostKeyChecking=noandUserKnownHostsFile=/dev/nullwhile using the Administrator account. This skips host authenticity checks (MITM risk) and executes commands as a high-privilege user on the target. Pin the host key (or use a known_hosts file) and run the remote task with a dedicated, least-privileged service account.
Next Steps
- Remove tracked secrets (
config/config.json,.env) from git, rotate the leaked tokens/passwords, and populate them during deployment via environment variables or a secrets manager. - Update
deploy.shto use a secure Git credential helper (e.g.,manager-coreorcachewith short TTL) or require manual authentication instead ofcredential.helper store, and scope the PAT to read-only if possible. - Harden
scripts/qreport_scheduler.shby enforcing SSH host key verification and switching to a restricted service user rather than the Administrator account before executing remote reports.