Platform Processes & Security Controls

Game Warden is a Department of Defense (DoD)-authorized DevSecOps platform designed to securely and efficiently deploy SaaS applications into government networks. The platform integrates security tooling, continuous integration/continuous deployment (CI/CD) pipelines, and governance processes to streamline software delivery while ensuring compliance with federal requirements.

---

Integrated tooling and CI/CD pipelines

Game Warden provides a managed CI/CD ecosystem powered by GitLab, which supports source code management, issue tracking, and pipeline automation. Pipelines enable automated code testing, container image scanning, hardening, and deployment to secured environments.

Image scanning and security tools

• Anchore Enterprise and Checkmarx supported Zed Attack Proxy - Used for container image security scanning, vulnerability identification, and compliance enforcement.
• ClamAV - Performs malware detection on container images.

Image scan results—including Common Vulnerabilities and Exposures (CVEs)—are visible in Findings within the Game Warden web app, providing transparency into your security posture.

---

Image management with Harbor Registry

Harbor is the secure container registry used by Game Warden. All container images pushed into Game Warden go through Harbor, where status tags are applied to indicate their scanning and hardening states.

Tags help track images as they progress through security checks and readiness for deployment.

Understanding images and containers

A container is a lightweight, portable package that contains an application along with all its required dependencies, ensuring consistent execution across different environments.

A container image is a static specification of this package, composed of multiple layers. The foundational layer is the base image, which provides core operating system components. Additional layers include required software packages, such as application binaries, runtime environments (e.g., nginx), or other dependencies.

Base image

Base images must remain unmodified after selection. Any customization must occur in layers built on top of the base image.

Game Warden supports applications structured with multiple containers, where each container is responsible for a distinct service or function within the overall application architecture.

---

Game Warden pipelines and deployment processes

Automated pipelinesDeployment workflow

Pipelines are sets of automated tasks that move your applications through scanning, hardening, and deployment stages. Game Warden engineers provision infrastructure, configure pipelines, and develop bootstrap scripts to automate CI/CD workflows.

You can monitor pipeline progress and security reviews via Findings.

1. Development:

• No Certificate to Field (CtF) required.
• Engineers configure the environment and validate basic functionality.

2. Staging:

• Requires a signed CtF.
• Extensive application and security testing.
• Requires Government Access Cards for environment access at IL4 and above.

3. Production:

• Live deployment environment with customer access.
• Monitored by Site Reliability Engineers (SREs) for stability and support.
• Requires Government Access Cards for environment access at IL4 and above.

How pipelines support Deployment Passport creation

The Game Warden pipelines do more than move your application through CI/CD stages — they also generate critical artifacts that make up your Deployment Passport.

As your container images progress through scanning, hardening, and security validation, the results and evidence gathered become part of the documentation package submitted for security approval.

These automated security checks, along with your application architecture and compliance data, are compiled by the Game Warden Security team to build a complete Deployment Passport — a required component for deployment into IL4+ environments.

---

Security hardening and binary reduction

Before deployment, all images undergo hardening to reduce security risks. The process includes:

• Restricting user permissions and removing unnecessary users/groups.
• Locking down file system permissions.
• Cleaning temporary files and broken links.

Hardening script example

#!/bin/sh

set -x #trace on
set -e #break on error
user_id=$1
hardening_platform=$2

echo "Using user " $user_id
echo "Hardening for " $hardening_platform

# Create the 'appuser' user and group used to launch processes
# The uid and gid will be set to 950 to avoid conflicts with offical users on the docker host.
# groupadd -r appuser -g 950 && \
#     useradd -u 950 -m -d /home/appuser -r -g appuser -s /sbin/nologin -c "restricted docker account" appuser

# mkdir /app
# chown -R appuser:appuser /app

#nginx specific commands
case $hardening_platform in
  nginx)
    # NGINX files for nonroot
    chown -R $user_id:$user_id /etc/nginx
    mkdir -p /var/cache/nginx
    chown -R $user_id:$user_id /var/cache/nginx
    mkdir -p  /var/log/nginx
    chown -R $user_id:$user_id /var/log/nginx

    # NGINX directory for data
    mkdir -p /var/www
    chown -R $user_id:$user_id /var/www
    mkdir -p /var/run
    touch /var/run/nginx.pid
    chown -R $user_id:$user_id /var/run/nginx.pid
    ;;
esac

sed -i -r "s/$user_id:!:/$user_id:x:/" /etc/shadow

# Remove unnecessary user accounts.
sed -i -r "/($user_id|root)/!d" /etc/group
sed -i -r "/($user_id|root)/!d" /etc/passwd
sed -i -r "/($user_id|root)/!d" /etc/shadow

# Remove interactive login shell for everybody but $user_id.
sed -i -r "/$user_id:/! s#^(.*):[^:]*$#\1:/sbin/nologin#" /etc/passwd

# Removing files generated by sed commands above (group-, passwd- and shadow-)
find $sysdirs -xdev -type f -regex '.*-$' -exec rm -f {} +

# Initial list of system directories
all_sysdirs="
  /bin
  /etc
  /lib
  /lib64
  /sbin
  /usr
"

# Filter out only existing directories
sysdirs=""
for dir in $all_sysdirs; do
  if [ -d "$dir" ]; then
    sysdirs="$sysdirs $dir"
  else
    echo "Directory $dir not found. Skipping."
  fi
done

# Ensure system dirs are owned by root and not writable by anybody else.
find $sysdirs -xdev -type d \
  -exec chown root:root {} \; \
  -exec chmod 0755 {} \;

# Remove existing crontabs, if any.
rm -fr /var/spool/cron

# Remove kernel tunables since we do not need them.
rm -fr /etc/sysctl*
rm -fr /etc/modprobe.d
rm -fr /etc/modules

# Remove fstab since we do not need them.
rm -f /etc/fstab

# Remove all but a handful of admin commands.
[ -d /usr/sbin ] && find /usr/sbin ! -type d \
  -a ! -name nologin \
  -delete

# Remove all but a handful of executable commands.

##executabe commands to remove
case $hardening_platform in
  dotnet)
    find /usr/bin ! -type d \
    -a ! -name cd \
    -a ! -name ls \
    -a ! -name sh \
    -a ! -name bash \
    -a ! -name dash \
    -a ! -name dir \
    -a ! -name env \
    -a ! -name rm \
    -a ! -name find \
    -a ! -name coreutils \
    -a ! -name test \
    -a ! -name dotnet \
    -delete
    ;;

  go)
    find /usr/bin ! -type d \
    -a ! -name cd \
    -a ! -name ls \
    -a ! -name sh \
    -a ! -name bash \
    -a ! -name dir \
    -a ! -name env \
    -a ! -name rm \
    -a ! -name find \
    -a ! -name coreutils \
    -a ! -name test \
    -delete
    ;;

  jdk)
    find /usr/bin ! -type d \
    -a ! -name cd \
    -a ! -name ls \
    -a ! -name sh \
    -a ! -name bash \
    -a ! -name dash \
    -a ! -name dir \
    -a ! -name env \
    -a ! -name rm \
    -a ! -name find \
    -a ! -name mkdir \
    -a ! -name coreutils \
    -a ! -name test \
    -a ! -name java \
    -delete
    ;;

  nginx)
    find /usr/bin ! -type d \
    -a ! -name cd \
    -a ! -name ls \
    -a ! -name sh \
    -a ! -name bash \
    -a ! -name dir \
    -a ! -name env \
    -a ! -name rm \
    -a ! -name find \
    -a ! -name grep \
    -a ! -name touch \
    -a ! -name sed \
    -a ! -name cat \
    -a ! -name coreutils \
    -a ! -name test \
    -delete
    ;;

  nodejs)
    find /usr/bin ! -type d \
    -a ! -name cd \
    -a ! -name ls \
    -a ! -name sh \
    -a ! -name bash \
    -a ! -name dir \
    -a ! -name env \
    -a ! -name rm \
    -a ! -name find \
    -a ! -name cat \
    -a ! -name coreutils \
    -a ! -name test \
    -delete
    ;;

  python)
    find /usr/bin ! -type d \
    -a ! -name cd \
    -a ! -name ls \
    -a ! -name sh \
    -a ! -name bash \
    -a ! -name dash \
    -a ! -name dir \
    -a ! -name env \
    -a ! -name rm \
    -a ! -name find \
    -a ! -name coreutils \
    -a ! -name test \
    -a ! -name python* \
    -a ! -name pip* \
    -delete
    ;;

  tomcat)
    find /usr/bin ! -type d \
    -a ! -name cd \
    -a ! -name ls \
    -a ! -name sh \
    -a ! -name bash \
    -a ! -name dash \
    -a ! -name dir \
    -a ! -name env \
    -a ! -name rm \
    -a ! -name find \
    -a ! -name mkdir \
    -a ! -name coreutils \
    -a ! -name test \
    -a ! -name chown \
    -delete
    ;;

  *)
    find /usr/bin ! -type d \
    -a ! -name cd \
    -a ! -name ls \
    -a ! -name sh \
    -a ! -name bash \
    -a ! -name dir \
    -a ! -name env \
    -a ! -name rm \
    -a ! -name find \
    -a ! -name coreutils \
    -a ! -name test \
    -delete
    ;;
esac

# Remove broken symlinks (because we removed the targets above).
find $sysdirs -xdev -type l -exec test ! -e {} \; -delete

rm -rf /tmp/*

Use the following example as a reference for applying the hardening script in your Docker build process.

Example Dockerfile for hardening

FROM registry.gamewarden.io/yourcompany/yourimage:1.0.0

USER 0

COPY hardening-scripts/hardening-script.sh /tmp/hardening-script.sh

RUN chmod +x /tmp/hardening-script.sh \
    && /tmp/hardening-script.sh 65532 nginx

USER 65532

---

Platform security validation

Game Warden’s platform security is validated through:

• Continuous security reviews by the government.
• Regular third-party penetration testing.
• Managed enforcement of security controls across infrastructure, Kubernetes platforms, and applications.

---

FAQs

Why does Second Front request Dockerfiles when containers are pushed?

We request Dockerfiles to support our custom container hardening process. Our hardening scripts remove unnecessary users, files, and commands from your base image. By reviewing your Dockerfile, we can better understand what elements your container needs to function correctly after hardening, allowing us to secure your container without breaking critical functionality.

Does an image go through the full pipeline on every run?

No. After the first full pipeline run, subsequent runs are significantly faster. Game Warden will compare vulnerabilities against previously approved justifications and only prompt for justification of any new findings.

What does the Game Warden custom hardening process include?

The hardening process varies depending on what your container includes (e.g., databases). Generally, it involves:

• Creating a non-root user with only necessary permissions.
• Removing unused user accounts and login shells.
• Locking down system directories and file permissions.
• Deleting unused files, binaries, kernel tunables, crontabs, and broken symlinks.
• Whitelisting only essential executables needed for your container to function.

We will work with your team to confirm that the hardened image preserves expected functionality.

What tool does Game Warden use to generate the Software Bill of Materials (SBOM)?

Game Warden uses Anchore Enterprise to generate SBOMs.

What security scanning tools does Game Warden use, and which ones should I use?

Game Warden uses the following tools:

• Trivy and Anchore Enterprise (which uses Grype and Syft) for CVE detection.
• Anchore Compliance for compliance checks.
• ClamAV for malware detection.

These scanners generate security findings that appear in Findings in the Game Warden web app.

We recommend that you pre-scan your images before pushing to Game Warden. Open-source tools such as Trivy and Grype can help identify most issues surfaced by our platform scanners. These tools are cost-effective and well-suited for early testing, even though they may not catch certain DoD-specific findings.