move npm-security container from private repo

[rickygarg]

Description

Moves NPM security container from private repo, to run npm i in an isolated container first.

[Copilot]

Pull request overview

This PR introduces a security-focused Docker container that validates NPM dependencies by running npm install in an isolated environment and scanning for known malicious files associated with the Sha1-Hulud malware (documented from Nov 24, 2025).

Key changes:

• Creates a containerized security scanner with malware hash detection
• Implements GitHub token validation to prevent write-access tokens
• Provides a reusable GitHub Actions workflow for CI/CD integration

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
npm-security/entrypoint.sh	Main security validation script with token checks, npm install, and hash-based malware detection
npm-security/README.md	Comprehensive documentation covering usage, security features, and integration examples
npm-security/Dockerfile	Alpine-based Node.js container configuration running as non-root user
npm-security/.npmrc	NPM configuration for GitHub Package Registry authentication
.github/workflows/verify-npm-security.yml	Reusable workflow for automated NPM security verification

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The working directory is set to /home/node/test in the Dockerfile, but these commands copy to ~/test/. Since the script runs as the 'node' user, ~ expands to /home/node/, making the destination /home/node/test/. However, the source path /app/ doesn't align with the /home/node/test working directory. The volume mount is expected at /app, but the script should work within the current directory. Consider using cp /app/package*.json . or clarifying the directory structure.

Suggested change

	if [ -f /app/package.json ] ; then cp /app/package.json ~/test/package.json; fi
	if [ -f /app/package-lock.json ] ; then cp /app/package-lock.json ~/test/package-lock.json; fi
	if [ -f /app/package.json ] ; then cp /app/package.json ./package.json; fi
	if [ -f /app/package-lock.json ] ; then cp /app/package-lock.json ./package-lock.json; fi

[Copilot]

The path /.env checks for a .env file in the root directory, but based on the volume mount at /app and working directory structure, this should likely be /app/.env or ./.env to check in the project directory. The current path would only catch a .env file in the container's root filesystem.

Suggested change

	if [ -f /.env ] ; then echo ".env file found. Exiting"; exit $EXIT_INSTALLATION_ERROR; fi
	if [ -f /app/.env ] ; then echo ".env file found. Exiting"; exit $EXIT_INSTALLATION_ERROR; fi

[Copilot]

[nitpick] The suspicious files output should be formatted for better readability and actionability. Consider iterating over the results to show the file path and hash separately, making it easier to identify which specific files triggered the alert.

Suggested change

	echo "$SUSPICIOUS_FILES"
	echo "The following suspicious files were found:"
	echo "$SUSPICIOUS_FILES" | while read -r line; do
	HASH=$(echo "$line" | awk '{print $1}')
	FILE=$(echo "$line" | awk '{print $2}')
	echo " File: $FILE"
	echo " Hash: $HASH"
	echo "-----------------------------"
	done

[rickygarg]

For better maintainability for future threats:

1. It will be better to move malicious checksums in a separate file under checksums folder. Then we can add a new file in this folder for each new kind of threat.

2. We can also create another folder patterns for simpler grep checks. For SHA1-Hulud, that could include a file with the following patterns:

_0x349291
_0x2b1a39

Separate thought: An agent can create PRs to malicious checksums & patterns based on information from daily security feeds.