원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
There is no time to spend late at night just Googling after hearing news of a security incident. In May 2026, malicious Visual Studio Code extensions were distributed, compromising developer machines and leaking approximately 3,800 internal source code repositories. In this situation, blindly deleting code or formatting your laptop will wipe out forensic evidence, preventing you from finding the root cause. Let's manually investigate package manager execution logs, global CLI timestamps, and active process privileges to see if you have been breached.
Package managers leave transaction records in the system cache directory during installation. npm dumps debug logs into the _logs folder within the npm config get cache path, and pnpm stashes artifacts in pnpm store path. Because malicious packages exfiltrate environment variables or credentials through scripts executed the moment they are installed, you must first inspect the lifecycle execution history.
The following command searches the logs from the past 14 days to catch unauthorized package additions or external script executions. Turn on your terminal and run the command below as is:
bash NPM_CACHE_DIR=$(npm config get cache) find $NPM_CACHE_DIR/_logs/ -type f -mtime -14 -exec grep -Hn "lifecycle" {} +
Check the result screen to see if unintended preinstall or postinstall hooks were executed. It takes 3 minutes. If there are no strange external URL communication records, you can breathe a sigh of relief from the fear of direct package-level contamination.
Attackers plant malicious binaries into global CLI tools or the npx cache to persist inside the laptop. Extract the list of globally installed packages and compare the file creation and modification dates in the binary folder with system logs to verify integrity.
bash npm list -g --depth=0 --json ls -lact $(npm config get prefix)/bin/
If the modification time overlaps with an unusual time zone, extract the hash value using the command below to cross-check.
bash shasum -a 256 $(npm config get prefix)/bin/
Package installation scripts run with the exact privileges of the developer account. You must kill daemon processes running in the background.
bash ps aux | grep -E "node|npm|pnpm|bun" | grep -v grep lsof -i -P -n | grep -E "node|npm|pnpm"
If a suspicious process is communicating with an external C2 server, catch and kill it immediately.
bash kill -9 [PID] npm config set ignore-scripts true
A frequent pattern in supply chain attacks is tampering with configuration files to hijack registries. Attackers embed malicious mirror server addresses into the .npmrc file within a project or into global configurations. Since they swap out download URL paths inside lockfiles to make you download malicious tarballs during actual installation, you must search all configuration values.
The procedure to check if unauthorized overrides are embedded in local and global configurations is as follows. First, extract the list of configuration bindings.
bash npm config list pnpm config list
Next, check if the internal private registry scope is set correctly.
bash npm config get @company:registry
Directly search whether external mirror addresses are hardcoded in the user home and project root configuration files.
bash grep -Rn "registry" ~/.npmrc ./.npmrc
Through these three steps, you can determine within 5 minutes if a strange mirror address has been registered.
Since package-lock.json and pnpm-lock.yaml files record the source URLs for dependency downloads, you need to scrub them for contamination using regular expressions.
bash grep -E '"resolved": "https?://' package-lock.json | grep -vE 'registry.npmjs.org|registry.corp.example'
If you use pnpm, enter the following command:
bash grep -E 'resolution: {tarball:' pnpm-lock.yaml | grep -vE 'registry.npmjs.org|registry.corp.example'
If a contaminated lockfile is found, you must delete it and rebuild it from scratch.
bash rm -rf node_modules package-lock.json pnpm-lock.yaml npm cache clean --force pnpm store prune npm config set registry https://registry.npmjs.org/ npm ci --ignore-scripts
By ignoring lifecycle script execution and reconstructing an immutable dependency tree, you can secure a pristine environment.
In Linux and Mac environments, malicious binaries plunder browser password stores and scrape AI API keys, AWS Access Keys, and SSH keys embedded in environment variables. You must check right now whether your credentials have been exposed in the terminal environment.
bash ls -la ~/.ssh/ env | grep -E 'TOKEN|KEY|SECRET|AUTH|AWS|GITHUB|OPENAI|ANTHROPIC' grep -E '(ghp_[A-Za-z0-9]{36}|AKIA[0-9A-Z]{16}|bearer)' ~/.zsh_history ~/.bash_history
If keys exposed in plain text appear, do not turn a blind eye and revoke them immediately. Also check the token scope logged into the GitHub CLI.
bash gh auth status
Nuke any Classic tokens that have access permissions to all repositories right away. When recreating a PAT, specify only targeted repositories and restrict read permissions to the minimum scope.
To isolate the local host and development processes, you should use a DevContainer structure. Create a .devcontainer/devcontainer.json file in your project root and configure the image as shown below.
json { "image": "mcr.microsoft.com/devcontainers/javascript-node:22", "postCreateCommand": "npm ci --ignore-scripts" }
Running a container this way ensures that package installation and building run completely isolated from your laptop's system credentials, fundamentally cutting off internal asset leakage pathways.
