Skip to content
This repository was archived by the owner on Jul 28, 2026. It is now read-only.

Fixed Java container installing gnupg - #45

Merged
dfreniche merged 4 commits into
mainfrom
fix-java-container
Jul 28, 2026
Merged

Fixed Java container installing gnupg#45
dfreniche merged 4 commits into
mainfrom
fix-java-container

Conversation

@dfreniche

Copy link
Copy Markdown
Collaborator

The container failed while starting, complains about OpenSSH, added GNUPG to avoid it.

Comment thread .devcontainer/Dockerfile
@@ -0,0 +1,12 @@
FROM mcr.microsoft.com/devcontainers/java:1-21-bookworm

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Semgrep identified an issue in your code:
By not specifying a USER, a program in the container may run as 'root'. This is a security hazard. If an attacker can control a process running as root, they may have control over the container. Ensure that a USER directive is defined in the Dockerfile.

To resolve this comment:

✨ Commit fix suggestion
  1. Keep the base image as-is, but add a USER directive in the Dockerfile so the container does not start as root.

  2. Place the USER directive after the RUN steps that need package installation, because apt-get usually requires root privileges.

  3. Switch to a non-root account that already exists in this base image, if available. For Microsoft devcontainer images, that is commonly vscode, so add USER vscode near the end of the Dockerfile.

  4. Update file ownership before switching users if later steps need write access to application directories. For example, use RUN chown -R vscode:vscode /path/to/app before USER vscode.

  5. Alternatively, if this image does not already include a non-root user, create one first and then switch to it with USER appuser. For example, add RUN useradd -m -u 10001 appuser and then USER appuser. Running as a non-root user limits what an attacker can do inside the container.

💬 Ignore this finding

Reply with Semgrep commands to ignore this finding.

  • /fp <comment> for false positive
  • /ar <comment> for acceptable risk
  • /other <comment> for all other reasons

Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by missing-user-definition.

🛟 Help? Slack #semgrep-help or go/semgrep-help.

Resolution Options:

  • Fix the code
  • Reply /fp $reason (if security gap doesn’t exist)
  • Reply /ar $reason (if gap is valid but intentional; add mitigations/monitoring)
  • Reply /other $reason (e.g., test-only)

You can view more details about this finding in the Semgrep AppSec Platform.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/ar as these containers run in GitHub's infra or in Instruqt, never on Atlas this "risk" is harmless. They can destroy the container if they want.

@dfreniche
dfreniche merged commit 9748e6f into main Jul 28, 2026
3 checks passed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant