← Back to transparency overview

Security Enhancements

Snapshot from repository file ".github/ENHANCEMENTS.md", last updated 2025-12-14 22:02:07 UTC

# Security and Quality Enhancements

This document describes the security, compliance, and quality enhancements implemented in this repository.

## Overview

We've implemented enterprise-grade security and compliance features to make these Docker images production-ready and compliant with modern security standards including BSI TR-03183.

## Enhancements Implemented

### 1. Automated Dependency Updates (Dependabot)

**File**: `.github/dependabot.yml`

Automatically monitors and updates:
- GitHub Actions versions (weekly)
- Docker base images (weekly)
- Creates pull requests for updates
- Labels PRs for easy triage

**Benefits**:
- Stay current with security patches
- Automatic vulnerability remediation
- Reduced maintenance burden

### 2. Security Scanning

**File**: `.github/workflows/security-scan.yml`

Implements comprehensive vulnerability scanning:
- **Trivy scanner** for CVE detection
- Scans on: push, PR, weekly schedule, manual trigger
- Results uploaded to GitHub Security tab
- SARIF format for GitHub Advanced Security
- JSON artifacts for audit trails
- Blocks on critical vulnerabilities (with warning)

**Detects**:
- OS package vulnerabilities
- Application dependencies
- Misconfigurations
- Exposed secrets
- License issues

### 3. Comprehensive Integration Tests

**File**: `.github/workflows/integration-tests.yml`

Full functional testing suite:

**Jena Tests**:
- Version verification
- RDF parsing (Turtle, N-Triples, etc.)
- Validation of invalid RDF
- SPARQL query execution with arq

**Fuseki Tests**:
- Server startup and health checks
- Admin authentication
- Dataset creation via API
- Data upload and retrieval
- SPARQL query endpoints
- Stats endpoint verification
- Log verification
- TDB2 support testing
- Data persistence across restarts
- Multiple dataset creation

**Coverage**: ~20 test scenarios covering critical functionality

### 4. SBOM Generation (BSI TR-03183 Compliance)

**Enhanced**: `.github/workflows/publish.yml`

Multiple SBOM formats and attestations:

1. **Docker BuildKit SBOM**: Built-in SBOM generation
2. **Syft SBOM**: SPDX JSON format for BSI compliance
3. **SLSA Provenance**: Build metadata attestation
4. **SBOM Attestation**: Signed and pushed to registry

**Compliance**:
- ✅ SPDX 2.3 format
- ✅ BSI TR-03183 requirements
- ✅ Cryptographically signed
- ✅ Attached to container images
- ✅ Downloadable artifacts

**Accessing SBOMs**:
```bash
# View attestations
docker buildx imagetools inspect ghcr.io/senticor-ai/jena-fuseki:5.6.0

# Download SBOM artifact from GitHub Actions runs
# Or use: syft packages ghcr.io/senticor-ai/jena-fuseki:5.6.0
```

### 4a. GitHub Pages for SBOM Transparency

**File**: `.github/workflows/publish-sbom-pages.yml`

Automated publication of SBOMs to GitHub Pages for public transparency:

**Features**:
- Automatically triggered after container image publication
- Creates user-friendly HTML interface for browsing SBOMs
- Provides command examples for verifying attestations
- Demonstrates BSI TR-03183 transparency requirements

**What Gets Published**:

A professional, human-readable HTML webpage featuring:
- Beautiful responsive design with compliance badges (BSI TR-03183, SLSA Level 3, SPDX 2.3)
- Downloadable SBOM files in SPDX format
- Command examples for accessing attestations (Docker, Syft, Cosign)
- Container image information
- Security features and compliance documentation
- Automatic timestamp updates

**Setup Instructions**:

See [GITHUB_PAGES_SETUP.md](GITHUB_PAGES_SETUP.md) for detailed setup guide.

**Quick Setup**:
1. Go to repository **Settings** → **Pages**
2. Set **Source** to "GitHub Actions"
3. Save - that's it!

Once enabled, the page will be live at `https://senticor-ai.github.io/jena-docker/` and automatically update after each container image release.

### 5. License Documentation

**File**: `LICENSES.md`

Comprehensive license information:
- All software components listed
- License texts and SPDX identifiers
- Source code locations
- Commercial use guidelines
- BSI TR-03183 compliance checklist
- Trademark notices

**Licenses Documented**:
- Apache 2.0 (Jena, Fuseki, Dockerfiles)
- GPL-2.0 with Classpath Exception (OpenJDK)
- MIT (Alpine packages, tini)
- GPL-2.0 and GPL-3.0 (Alpine utilities)

### 6. Security Policy

**File**: `SECURITY.md`

Formal security program:
- Supported versions policy
- Vulnerability reporting process
- Response timelines
- Security best practices
- Production deployment guidelines
- Known security considerations
- Compliance standards checklist

**Features**:
- Coordinated disclosure policy
- Security contact information
- Update subscription options
- Hardening recommendations

## Base Image Security

### Current Base: eclipse-temurin:21-jre-alpine

**Why Alpine**:
- ✅ **Small size**: ~62 MB base (vs ~200 MB for Debian)
- ✅ **Minimal attack surface**: Fewer packages installed
- ✅ **musl libc**: Smaller, simpler than glibc
- ✅ **apk package manager**: Efficient and secure
- ✅ **Regular security updates**: Active security team
- ✅ **Well-tested**: Industry standard for containers

**Security Features**:
- No unnecessary packages
- Minimal shell environment
- Security patches applied via weekly Dependabot
- Compatible with read-only filesystems
- SELinux compatible (with :Z flag)

## Supply Chain Security

### SLSA Level 3 Compliance

We achieve SLSA Level 3 through:

1. **Source**: Public GitHub repository
2. **Build**: GitHub-hosted runners (trusted)
3. **Provenance**: Automatically generated and signed
4. **Hermetic**: Reproducible builds with pinned versions
5. **Isolated**: Each build in fresh environment
6. **Parameterless**: No user input during build
7. **Signed**: Sigstore attestations

### Build Provenance

Every image includes:
- **Source commit SHA**: Exact code version
- **Build timestamp**: When it was built
- **Builder identity**: GitHub Actions
- **Build parameters**: Dockerfile, context
- **Dependencies**: Full SBOM

### Verification

```bash
# Verify image provenance (requires cosign)
cosign verify-attestation \
  --type slsaprovenance \
  ghcr.io/senticor-ai/jena-fuseki:5.6.0

# Check SBOM
syft packages ghcr.io/senticor-ai/jena-fuseki:5.6.0
```

## License Compliance

### All Components Apache 2.0 Compatible

The stack is **commercially usable** without restrictions:

| Component | License | Commercial Use |
|-----------|---------|----------------|
| Dockerfiles | Apache 2.0 | ✅ Yes |
| Apache Jena | Apache 2.0 | ✅ Yes |
| Apache Fuseki | Apache 2.0 | ✅ Yes |
| OpenJDK | GPL-2.0 + Classpath Exception | ✅ Yes (exception allows linking) |
| Alpine Linux | MIT + GPL runtime | ✅ Yes (runtime only) |
| tini | MIT | ✅ Yes |

**Note**: GPL components (bash, coreutils) are runtime dependencies only, not linked libraries, so they don't impose GPL obligations on users.

## BSI TR-03183 Compliance Checklist

German Federal Office for Information Security (BSI) Technical Guideline TR-03183:

- ✅ **4.1 SBOM**: SPDX format SBOM attached to every image
- ✅ **4.2 Provenance**: SLSA provenance with cryptographic signing
- ✅ **4.3 Vulnerability Disclosure**: Security.md with coordinated disclosure
- ✅ **4.4 Software Updates**: Dependabot for automated updates
- ✅ **4.5 License Information**: LICENSES.md with complete information
- ✅ **4.6 Cryptographic Signatures**: Sigstore attestations
- ✅ **4.7 Secure Development**: GitHub branch protection, code review
- ✅ **4.8 Transparency**: Public builds, audit logs
- ✅ **4.9 Reproducibility**: Pinned versions, deterministic builds

## Additional Security Measures

### Image Hardening

1. **Non-root user**: Fuseki runs as UID 1000
2. **Minimal packages**: Only essential tools installed
3. **No sensitive data**: Passwords generated at runtime
4. **Pinned versions**: No floating tags in Dockerfiles
5. **Health checks**: Built into docker-entrypoint.sh
6. **Graceful shutdown**: SIGINT handling with tini

### Development Security

1. **Branch protection**: Require reviews, status checks
2. **Signed commits**: Recommended for maintainers
3. **Secret scanning**: GitHub secret scanning enabled
4. **Dependabot alerts**: Automatic security advisories
5. **Code scanning**: Trivy scans on every PR

## Testing Coverage

### Test Matrix

| Component | Unit Tests | Integration Tests | Security Scans | Compliance |
|-----------|-----------|-------------------|----------------|------------|
| Jena | Basic | ✅ Full | ✅ Weekly | ✅ SBOM |
| Fuseki | Basic | ✅ Full | ✅ Weekly | ✅ SBOM |
| Docker Build | - | ✅ CI/CD | ✅ Per PR | ✅ Provenance |

### Test Scenarios

**Jena**: 4 scenarios
- Version verification
- RDF parsing and validation
- Format conversion
- SPARQL queries

**Fuseki**: 16 scenarios
- Server startup and health
- Authentication and authorization
- Dataset CRUD operations
- Data upload/download
- SPARQL endpoint testing
- TDB2 support
- Data persistence
- Multi-dataset support

## Continuous Monitoring

### Automated Scans

- **Daily**: Dependabot checks
- **Weekly**: Trivy vulnerability scans
- **Per PR**: Integration tests, security scans
- **Per push**: Build tests
- **Per release**: Full suite + SBOM generation

### Alerting

- GitHub Security tab for CVEs
- Dependabot PRs for updates
- Email notifications for security advisories
- RSS feed available

## Future Enhancements

Potential additions:

- [ ] Runtime security monitoring (Falco)
- [ ] Image signing with organization key
- [ ] CycloneDX SBOM format (in addition to SPDX)
- [ ] SLSA Level 4 (hermetic builds)
- [ ] Performance benchmarking
- [ ] Chaos engineering tests
- [ ] Compliance reporting dashboard

## References

- **BSI TR-03183**: https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Cyber-Sicherheit/technische-richtlinien_node.html
- **SLSA Framework**: https://slsa.dev/
- **SPDX**: https://spdx.dev/
- **Trivy**: https://trivy.dev/
- **Syft**: https://github.com/anchore/syft
- **Sigstore**: https://www.sigstore.dev/

---

Last Updated: 2025-11-16
Maintainers: [Add your team]