Posture score
79%
Passing
19
Failing
5
Warnings
0
▶About this report — how to read it and how to verify timestamps
What you are looking at
This is a read-only compliance view generated by Scorifya Controls, a self-hosted SOC 2 readiness tool. It reflects the live state of Foundry Labs, Inc.'s control environment — this is not a curated PDF export. The data is queried directly from their instance at the time you load this page. You have no ability to modify anything through this link.
Automated checks
Automated checks run against Foundry Labs, Inc.'s cloud infrastructure (AWS, GitHub, GCP, Azure) using read-only API credentials stored on their server. Each check is tagged with the framework criteria it provides evidence for: AICPA Trust Services Criteria (TSC 2017) for SOC 2, PCI DSS 4.0.1 requirement numbers, ISO/IEC 27001:2022 Annex A controls, and HIPAA Security Rule citations (45 CFR). Use the Framework selector on the report to narrow the checks table to a single framework's evidence (rows without a mapping to that framework are hidden and excluded from the posture score), or leave it on All to see everything. Results shown here are the most recent run. As part of your engagement, you should independently verify material findings directly in their cloud consoles — these results are a starting point, not a substitute for your own testing.
Manual controls and attestations
Manual controls cover areas that cannot be automated: security awareness training, access reviews, vendor assessments, incident response testing, and similar. For each control, Foundry Labs, Inc. has designated an owner, recorded notes, attached evidence files, and set a next-review date. A control marked Compliant means the owner has attested that the control is operating effectively, with supporting evidence available below.
RFC 3161 cryptographic timestamps: what the DigiCert badge means
When Foundry Labs, Inc.saves a manual control attestation, Scorifya Controls immediately sends a SHA-256 fingerprint of the attestation data to DigiCert's Timestamp Authority (TSA). DigiCert signs that fingerprint with the current time and returns a timestamp token (a .tsr file). This token is stored alongside the attestation in their database.
The token proves two things independently of Foundry Labs, Inc. or Scorifya:
- The attestation data existed at the timestamp shown — it cannot have been backdated.
- The data has not been modified since — any change would produce a different fingerprint that no longer matches the token.
DigiCert has no knowledge of what the data contains — they only see the hash. They have no relationship with Foundry Labs, Inc. or Scorifya beyond providing a public timestamping service.
About the Timestamp Authorities
Timestamps are issued by DigiCert (primary) or Sectigo (fallback if DigiCert is unreachable at the moment of attestation). Both are among the world's largest certificate authorities, and both have their TSA root certificates included in the Microsoft Windows Root Certificate Program, Apple trust stores, Adobe Approved Trust List (AATL — used by Acrobat), and Java. They are widely used for code signing, legal documents, and financial records. RFC 3161 is the IETF standard for trusted timestamping, published in 2001 and adopted across regulated industries.
Each attestation below shows which TSA issued its timestamp. The expandable verification command is pre-filled with the correct CA certificate URL for that specific TSA.
How to independently verify a timestamp
For any attestation showing a verified badge, you can verify the timestamp yourself using OpenSSL (standard, pre-installed on macOS and Linux). No account or API key is needed. The exact commands — including the correct CA certificate for that attestation's TSA — are shown in the expandable Verify with OpenSSL section under each control.
- Click .tsr ↓ next to the control to download the timestamp token.
- Expand Verify with OpenSSL on that control — copy and run the two commands shown (one fetches the CA cert, one runs the verification).
- Verification: OK means the TSA confirmed this exact content existed at the timestamp shown. Any other result means the token is invalid or the data was modified after timestamping.
The content hash covers: control identifier, attestation status, owner, notes, evidence filenames, and the attestation timestamp. Evidence file contents are not hashed — verify those directly by reviewing the attached files.
aws
| Check | Status |
|---|---|
GuardDuty enabled in all regions Amazon GuardDuty provides continuous threat detection and must be active in every region. | FAIL |
MFA enabled for all IAM users All IAM users with console access must have MFA enabled. Users without MFA are an immediate audit finding. | PASS |
No credentials unused for 90+ days IAM credentials unused for 90 or more days should be disabled or removed. | PASS |
No security groups expose SSH/RDP/DB ports to the internet Security groups must not allow 0.0.0.0/0 access to administrative or database ports (SSH, RDP, Postgres, MySQL, MSSQL, MongoDB, Redis, Elasticsearch, Memcached). PCI 1.4.1 explicitly requires restricting inbound traffic from untrusted networks. | PASS |
RDS instances use non-default master username The RDS master username cannot be renamed after creation. Well-known defaults (admin, postgres, root, sa, mysql, oracle, master) are the first attackers try in credential spraying and fail PCI 2.2.5 (vendor defaults). | PASS |
Root account has no active access keys The AWS root account should never have active access keys. Root keys cannot be scoped and represent full account compromise if leaked. | FAIL |
S3 public access block enabled All S3 buckets should have public access blocked at the account level. | PASS |
Strong password policy configured IAM password policy must enforce minimum length (14+), complexity, and rotation requirements. | PASS |
azure
| Check | Status |
|---|---|
Azure Storage account public blob access disabled All storage accounts must have Allow Blob Public Access set to Disabled to prevent unintentional data exposure. | FAIL |
Key Vaults use Azure RBAC Every Key Vault should use Azure RBAC for data-plane authorization instead of the legacy access-policy model, so access changes surface in IAM reviews. | FAIL |
MFA enforced via Security Defaults or Conditional Access MFA must be enforced for all users via Azure Security Defaults or a Conditional Access policy. | FAIL |
Microsoft Defender for Cloud enabled on key workloads Defender for Cloud Standard tier must be enabled for VMs, SQL, App Services, Storage, and Containers. | PASS |
No NSG rule opens SSH/RDP to the internet No Network Security Group rule should allow inbound TCP 22 or 3389 from Internet / 0.0.0.0/0 / *. | PASS |
No stale Azure AD guest users Guest users who have not signed in for 90+ days (or have never signed in and were invited 90+ days ago) should be reviewed and removed. | PASS |
Privileged Identity Management activated for admin roles Global Administrator and Privileged Role Administrator assignments should be managed through Privileged Identity Management (PIM) as just-in-time eligibilities, not permanent active assignments. Requires Entra ID P2 licensing. | PASS |
gcp
| Check | Status |
|---|---|
2-Step Verification enforced for all Google Workspace users All Google Workspace users must be enrolled in 2-Step Verification. Requires domain-wide delegation to the Admin SDK. | PASS |
GCS buckets block public access All Cloud Storage buckets must have Public Access Prevention enforced and no allUsers/allAuthenticatedUsers IAM bindings. | PASS |
No firewall rule opens SSH/RDP to the internet No VPC firewall rule should allow ingress to TCP 22 or 3389 from 0.0.0.0/0 — the most common exploit path for GCE instances. | PASS |
OS Login is enforced at the project level OS Login centralizes SSH access to Compute Engine through IAM identities instead of instance metadata keys; enforce it project-wide. | PASS |
Primitive IAM roles (Owner/Editor) not assigned to users The Owner and Editor primitive roles grant broad permissions and should not be assigned to human users in production. | PASS |
The default VPC network has been removed The auto-created 'default' VPC ships with permissive firewall rules and no flow logs; every benchmark recommends deleting it in production projects. | PASS |
Uniform bucket-level access enabled on GCS buckets Uniform bucket-level access must be enabled to ensure consistent IAM-only access control with no legacy ACLs. | PASS |
github
| Check | Status |
|---|---|
2FA required for all org members GitHub organization must require 2FA for all members. | PASS |
Dependabot security alerts enabled Dependabot must be enabled on all repositories to detect known vulnerabilities in dependencies. | PASS |
Manual controls(3 of 5 attested compliant)
Each compliant attestation carries an RFC 3161 timestamp from a trusted Certificate Authority (DigiCert or Sectigo), independently verifiable with OpenSSL.
Governance
Annual CMMC L1 self-assessment and SPRS affirmation
CMMC L132 CFR 170.22CompliantA CMMC Level 1 self-assessment against all 17 practices has been completed within the past 12 months, and a senior official has affirmed continuing compliance in the Supplier Performance Risk System (SPRS). The assessment record and the affirmation date are retained.
"Reviewed by demo admin. Evidence file uploaded; placeholder for demo purposes."
/uploads/demo/manual-cmmc-sprs_affirmation-evidence.pdfDigiCert Trusted G4 RSA4096 SHA256 TimeStamping CA verified· 8/18/2026, 9:06:08 AM
SHA-256: 6d616e75616c2e636d6d632e737072735f61666669726d6174696f6e3a64656d
Verify with OpenSSL ▾
# 1. Download the .tsr file above # 2. Get the TSA root certificate (DigiCert Trusted G4 RSA4096 SHA256 TimeStamping CA): # curl -O https://cacerts.digicert.com/DigiCertTrustedG4RSA4096SHA256TimeStampingCA.crt.pem # 3. Verify: openssl ts -verify \ -in tsr-manual.cmmc.sprs_affirmation-*.tsr \ -digest 6d616e75616c2e636d6d632e737072735f61666669726d6174696f6e3a64656d \ -CAfile $(basename https://cacerts.digicert.com/DigiCertTrustedG4RSA4096SHA256TimeStampingCA.crt.pem) # Expected: Verification: OK
FCI scoping documented
CMMC L1AC.L1-3.1.1CompliantThe systems, storage locations, and external connections that store, process, or transmit Federal Contract Information are identified and documented, including which contracts the FCI relates to. Reviewed at least annually and when systems or contracts change. Knowing where FCI lives is the precondition for limiting access to it.
"Reviewed by demo admin. Evidence file uploaded; placeholder for demo purposes."
/uploads/demo/manual-cmmc-fci_scoping-evidence.pdfDigiCert Trusted G4 RSA4096 SHA256 TimeStamping CA verified· 8/18/2026, 9:06:08 AM
SHA-256: 6d616e75616c2e636d6d632e6663695f73636f70696e673a64656d6f
Verify with OpenSSL ▾
# 1. Download the .tsr file above # 2. Get the TSA root certificate (DigiCert Trusted G4 RSA4096 SHA256 TimeStamping CA): # curl -O https://cacerts.digicert.com/DigiCertTrustedG4RSA4096SHA256TimeStampingCA.crt.pem # 3. Verify: openssl ts -verify \ -in tsr-manual.cmmc.fci_scoping-*.tsr \ -digest 6d616e75616c2e636d6d632e6663695f73636f70696e673a64656d6f \ -CAfile $(basename https://cacerts.digicert.com/DigiCertTrustedG4RSA4096SHA256TimeStampingCA.crt.pem) # Expected: Verification: OK
Physical Safeguards
Media sanitized before disposal or reuse
CMMC L1MP.L1-3.8.3CompliantInformation system media containing Federal Contract Information, paper and digital, is sanitized or destroyed before disposal or release for reuse, with a record of what was sanitized or destroyed, when, how, and by whom.
"Reviewed by demo admin. Evidence file uploaded; placeholder for demo purposes."
/uploads/demo/manual-cmmc-media_disposal-evidence.pdfDigiCert Trusted G4 RSA4096 SHA256 TimeStamping CA verified· 8/18/2026, 9:06:08 AM
SHA-256: 6d616e75616c2e636d6d632e6d656469615f646973706f73616c3a64656d6f
Verify with OpenSSL ▾
# 1. Download the .tsr file above # 2. Get the TSA root certificate (DigiCert Trusted G4 RSA4096 SHA256 TimeStamping CA): # curl -O https://cacerts.digicert.com/DigiCertTrustedG4RSA4096SHA256TimeStampingCA.crt.pem # 3. Verify: openssl ts -verify \ -in tsr-manual.cmmc.media_disposal-*.tsr \ -digest 6d616e75616c2e636d6d632e6d656469615f646973706f73616c3a64656d6f \ -CAfile $(basename https://cacerts.digicert.com/DigiCertTrustedG4RSA4096SHA256TimeStampingCA.crt.pem) # Expected: Verification: OK
Physical access devices controlled
CMMC L1PE.L1-3.10.5Not StartedKeys, badges, access cards, and other physical access devices for areas housing Federal Contract Information are inventoried, issued against named individuals, and recovered or deactivated when no longer needed.
Visitors escorted and activity logged
CMMC L1PE.L1-3.10.3Not StartedVisitors to facilities housing systems with Federal Contract Information are escorted, their activity is monitored, and physical access is logged. For fully cloud-hosted environments, the provider's physical-access responsibility and any office areas where FCI is handled are both addressed.