Enterprise Assessment
An enterprise review should evaluate both the GoForj source baseline and the system your organization builds with it. GoForj can provide evidence for the first boundary. Your application and platform teams own the second.
Start with the Adoption Scope
List the exact GoForj repositories and versions the application uses. Compare them with Repository Coverage, then retain the dependency graph or SBOM produced for the reviewed revision.
For Apps created by GoForj, include the framework version, selected first-party libraries and drivers, starter kit, generated source committed to the application, and any application-owned modifications.
Assessed Repository Estate
The baseline covers all 21 repositories below. The grouping makes the reviewed security boundaries visible, while Repository Coverage maps each repository to its exact control profile and current evidence.
| Reviewed Area | Primary Security Focus | Repositories |
|---|---|---|
| Framework and applications | Generation, templates, application dependencies, and workflow examples | goforj, docs |
| Data and workflows | Drivers, remote services, credentials, retries, and distributed coordination | cache, events, metrics, queue, scheduler, storage |
| Network and process boundaries | HTTP behavior, redirects, headers, command execution, mail, and transport security | execx, httpx, mail, web |
| Configuration and sensitive values | Encryption, environment secrets, serialization, and safe defaults | crypt, env, null |
| Generation and developer tooling | Remote repository input, generated code, terminal output, diagnostics, and helper behavior | atlas, collection, console, godump, str, wire |
Evidence Checklist
| Assessment Area | GoForj Evidence | Enterprise Evidence |
|---|---|---|
| Source governance | Public source, pull requests, immutable workflow references, and repository history | Approved source intake, ownership, change control, and internal review records |
| Static analysis | CodeQL findings for enrolled repositories plus vet and repository-specific checks | Analysis of application-owned code and organization-specific rules |
| Dependency risk | govulncheck, npm audit, Dependency Review, Dependabot, and documented exact exceptions | Approved versions, internal advisory feeds, remediation policy, and patch deployment records |
| Inventory | Validated CycloneDX CI SBOMs for discovered manifests | Application and release SBOM retention, signing, and asset inventory |
| Secrets | Full-history Gitleaks scanning | Secrets manager, rotation, access review, and production leak detection |
| Runtime security | Hardened framework behavior and Production Hardening guidance | Network policy, identity, authorization, encryption, logging, backups, and operator controls |
| Threat modeling | GoForj trust boundaries, threats, mitigations, and residual risks | Application data flows, abuse cases, authorization, tenant boundaries, and accepted risks |
| Incident response | Organization-wide reporting, response targets, and coordinated disclosure policy | Internal triage, escalation, notification, forensics, recovery, and exercise evidence |
| Release integrity | Versioned public Go modules, checksum transparency, and CI results | Approved source intake, build system, artifact signing, provenance, promotion, and rollback controls |
Questions the Baseline Can Answer
- Which GoForj repositories are included?
- Which automated controls run against each repository?
- Does scanning discover nested modules and lockfiles?
- What evidence does each control produce?
- What limitations and unresolved upstream exceptions are documented?
- Which compatibility changes were necessary to select fixed dependencies?
Questions the Adopting Enterprise Must Answer
- Which source revision and generated output were approved?
- Who can change dependencies, workflows, branch rules, and releases?
- Where are application secrets stored and how are they rotated?
- Which routes, diagnostics, metrics, databases, queues, caches, and storage systems are network-accessible?
- How are identity, authorization, tenant isolation, audit retention, and data classification implemented?
- How are build artifacts signed, promoted, deployed, rolled back, and retained?
- How quickly must dependency and application findings be remediated?
- How is incident response tested?
Suggested Review Package
Provide reviewers with:
- This Security Assurance entry point.
- The control definitions and limits.
- The GoForj Threat Model, extended for the application and deployment.
- The repository coverage matrix filtered to adopted components.
- The application dependency graph and retained SBOMs.
- Links or exports for the latest successful required workflows and open security findings.
- The source and build integrity record for the approved framework version and deployable application artifact.
- The application's data-flow diagram, deployment architecture, authorization model, and production hardening record.
- The enterprise exception register and remediation owners.
Interpreting the Result
A green workflow is evidence that a defined check passed for one revision. It is not an enterprise approval by itself. Approval should combine this evidence with the application's architecture, deployment controls, data sensitivity, and the enterprise's own risk criteria.