Create anchore.yml #86
Conversation
Add anchore grype action https://github.com/anchore/scan-action
WalkthroughThis pull request introduces a new GitHub Actions workflow file named Changes
Sequence Diagram(s)sequenceDiagram
participant Developer
participant GitHub Actions
participant Docker
participant Anchore Grype
participant GitHub
Developer->>GitHub Actions: Push code or create PR
GitHub Actions->>Docker: Checkout code
GitHub Actions->>Docker: Build Docker image
GitHub Actions->>Anchore Grype: Scan Docker image for vulnerabilities
Anchore Grype-->>GitHub Actions: Return scan results
GitHub Actions->>GitHub: Upload SARIF report
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
|
This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (3)
.github/workflows/anchore.yml (3)
20-21: Consider increasing the frequency of security scans.The current schedule (Thursday at 16:41 UTC) might not be frequent enough for security-critical Docker images. Consider running scans daily during off-peak hours to catch vulnerabilities sooner.
- - cron: '41 16 * * 4' + - cron: '0 2 * * *' # Daily at 2 AM UTC
36-37: Enhance Docker build security.Consider adding
--no-cacheflag to ensure fresh builds and prevent cache poisoning attacks. Also, consider adding platform specification for better reproducibility.- run: docker build . --file Dockerfile --tag localbuild/testimage:latest + run: docker build . --file Dockerfile --tag localbuild/testimage:latest --no-cache --platform linux/amd64
45-48: Add retention policy for scan results.Consider adding a retention period for the SARIF reports to maintain a history of security scans while managing storage efficiently.
uses: github/codeql-action/upload-sarif@v3 with: sarif_file: ${{ steps.scan.outputs.sarif }} + retention-days: 90
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
.github/workflows/anchore.yml(1 hunks)
🔇 Additional comments (2)
.github/workflows/anchore.yml (2)
23-31: LGTM! Well-configured permissions following security best practices.
The permissions are properly scoped following the principle of least privilege, with clear documentation for each permission's purpose.
36-37: Verify Dockerfile location and contents.
Let's ensure the Dockerfile exists and contains proper security configurations.
✅ Verification successful
Dockerfile exists and follows security practices, but requires user configuration
The Dockerfile and its associated scripts implement several security best practices:
- Uses a specific Alpine version (3.20.3) as base
- Creates a non-root 'tor' user and group
- Runs the Tor process as non-root via su-exec
- Implements proper signature verification during build
- Includes healthcheck
- Proper permission handling in entrypoint script
However, users should be aware of:
- Default configuration in config.sh needs to be customized (nickname, contact info)
- Control port password is using a default value
- Exit policy is restrictive by default (reject :)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify Dockerfile existence and basic security configurations
# Check if Dockerfile exists in the root
if [ -f "Dockerfile" ]; then
echo "Dockerfile found"
# Check for common security best practices
echo "Checking Dockerfile contents:"
grep -E "^FROM|^USER|^HEALTHCHECK|^COPY|^ADD" Dockerfile
# Check if using root user
if ! grep -q "^USER" Dockerfile; then
echo "WARNING: No USER instruction found - container might run as root"
fi
else
echo "ERROR: Dockerfile not found in repository root"
fi
Length of output: 560
Script:
#!/bin/bash
# Let's check the complete Dockerfile contents to better understand the security context
cat Dockerfile
# Also check the referenced scripts for any security-related configurations
echo -e "\nChecking entry-point.sh:"
cat entry-point.sh
echo -e "\nChecking healthcheck.sh:"
cat healthcheck.sh
echo -e "\nChecking config.sh:"
cat config.sh
Length of output: 3180
Change severity-cutoff from critical to high Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Add anchore grype action
https://github.com/anchore/scan-action
Summary by CodeRabbit