Security Considerations

Secure User Story Coverage credentials, network access, and automation flows.

Best practices for running User Story Coverage securely and reliably.

The tool runs in your environment and stores outputs on your systems, so the main risks are credential exposure, weak access control, and misconfigured network trust.

Use Troubleshooting when SSL, token, or git access checks fail.

Data Handling

What stays in your environment: all generated reports (HTML, JSON, Confluence pages, Jira/ADO updates), source code and repository access, report data and coverage metrics.

What is sent to SeaLights: tagging data (ticket IDs and file paths) during the tagging phase; API requests to read coverage data during the report phase.

What is sent to other systems: Jira/ADO (coverage percentages and summaries, if you use the publish scripts), Confluence (coverage report pages, if you publish detailed reports), GitHub/GitLab/Bitbucket (read-only access to PRs and commits).

Credential Management

Protect credentials at rest, in transit, and during rotation.

Store Credentials Securely

Use environment variables or your CI/CD secret manager for tokens and passwords.

Keep shared defaults in settings files and keep credentials in a separate local-only file when needed.

Use Configuration for secure setup patterns.

Protect Settings Files

Keep credential files out of source control.

Add local credential files such as settings, credentials, *_credentials.json, and .env to .gitignore, then verify they stay ignored before you commit.

Encode Basic auth credentials

echo -n "[e-mail]:api_token" | base64

Use the result as the value for a Basic <encoded> authorization header.

Use Secret Management in CI/CD

Inject secrets at runtime instead of storing them in repository files. Choose the secret-management path that matches your CI system.

GitHub Actions

✅ Prerequisites

• Repository or organization secrets already exist.
• The workflow can read those secrets.

🚀 Steps

1

Create the secrets

Add the required secret values in GitHub.

2

Reference them in the workflow

Expose the secret values as environment variables in the workflow job.

3

Run the workflow

Confirm the job reads the secrets without printing them.

📤 Expected outcome

The workflow receives the required credentials at runtime without storing them in the repository.

Jenkins

✅ Prerequisites

• The credentials already exist in Jenkins Credentials.
• The pipeline can reference those credentials.

🚀 Steps

1

Store the credentials

Create the credential entries in Jenkins.

2

Bind them in the pipeline

Reference the stored credentials from the pipeline environment.

3

Run and verify

Confirm the job reads the values without exposing them in logs.

📤 Expected outcome

The pipeline reads the credentials from Jenkins at runtime instead of from repository files.

GitLab CI/CD

✅ Prerequisites

• The CI/CD variables already exist in GitLab.
• Sensitive values are marked as masked or protected where needed.

🚀 Steps

1

Create the variables

Add the required values in GitLab CI/CD variables.

2

Protect sensitive values

Mark secret values as masked or protected based on your branch policy.

3

Run the pipeline

Confirm the job can read the values without printing them.

📤 Expected outcome

The pipeline receives the required credentials securely at runtime.

Network and Data Security

Protect transport security, network reachability, and local report data.

Report File Permissions

chmod 700 reports/              # Only owner can access
chmod 600 reports/*.html        # Read/write for owner only

Data Retention

find reports/ -name "*.html" -mtime +90 -delete
find reports/ -name "ReportInfo_*.json" -mtime +90 -delete

Git and CI/CD Security

Apply these controls when the workflow clones repositories or runs in automation.

What You Don't Need to Worry About

Since reports stay in your environment, you don't need report-data encryption beyond standard file system security, transmission security (reports aren't sent anywhere), complex data classification (coverage metrics are typically internal-use data), or extensive audit logging beyond standard system logs. Focus your security effort on protecting API tokens and following standard file security practices.