In this article
SOC 2 Type 1 evaluates control design at a specific date. SOC 2 Type 2 also evaluates whether controls operated effectively over a period of time. OpenHack supports both with application security scanning, remediation trails, and downloadable SAST and Supply Chain reports.
When your auditor asks how you find and fix software vulnerabilities, those reports help you show the work your team has done.
What is the difference between SOC 2 Type 1 and Type 2?
| SOC 2 Type 1 | SOC 2 Type 2 | |
|---|---|---|
| Assessment | Control design as of a specific date | Control design and operating effectiveness over a period |
| Application security evidence | Scanning setup, findings, and a documented review process | Scan records, reviewed findings, and remediation evidence across the period |
Both are examinations performed by an independent CPA firm against the Trust Services Criteria in scope for your organization. See AICPA's SOC overview for more on the framework.
How does OpenHack support SOC 2 compliance?
OpenHack's security platform helps your team find vulnerabilities in code and dependencies, investigate their impact, and review security findings in GitHub. Export the results so your auditor can follow the same work your engineers are already doing.
SAST reports: application code vulnerabilities
Static application security testing (SAST) examines source code for security vulnerabilities.
An authorization bypass in an API or SQL injection in a database query can put customer data at risk. OpenHack scans your application for these issues and brings the findings into your project's Vulnerabilities view.
The SAST report aggregates findings across scans, with an executive risk summary, severity breakdown, affected code locations, and a remediation trail. Your team can use it to explain which issues need attention and how findings have changed across scans.
View a sample SAST report (PDF)
Supply Chain reports: dependency vulnerabilities
Software composition analysis (SCA) identifies risks in third-party dependencies. OpenHack's Supply Chain scans identify known vulnerabilities in direct and transitive dependencies, helping your team decide which packages need attention.
The Supply Chain report includes scan coverage, dependency vulnerabilities, license information, and dependency health. Dependency paths help you trace how an affected package entered your project, so you can identify which dependency needs an upgrade. Pair the report with the upgrade pull request and a follow-up scan to show the issue was addressed.
View a sample Supply Chain report (PDF)
AI pentesting: demonstrate the impact
OpenHack's AI pentesting tests applications and APIs for exploitable weaknesses. Its verification workflow attempts exploits in a sandbox or browser, giving engineers concrete evidence to investigate and reproduce.
An authorization finding becomes much more useful when you can demonstrate that one account can access another account's data. Keep that evidence with the fix and retest results to show what was at risk and how your team responded.
Which SOC 2 controls does OpenHack help support?
Access controls and application boundaries: CC6.1 and CC6.6
OpenHack finds issues such as authentication bypass, IDOR, SSRF, and path traversal. These findings help your team identify where an application allows access or actions it should prevent.
For your audit, connect the finding to the code change and verification result. That creates a clear record of the weakness, the response, and the follow-up test.
Secrets and sensitive data: CC6.7
Exposed credentials and data leaks can undermine otherwise well-designed access controls. OpenHack's code scanning identifies hardcoded secrets, data exposure, and information disclosure issues so your team can address them.
If a credential is exposed, rotate it and remove the exposure. Retain the finding, fix, and rotation record as evidence of how you protected sensitive information.
Vulnerability management and ongoing review: CC7.1 and CC4.1
OpenHack's scan results and remediation trails help your team follow new, persisting, and resolved findings. For Type 1, show the scanning and review process you have established. For Type 2, retain evidence that your team followed it throughout the examination period.
Set remediation deadlines in your security policy and use finding records, tickets, and fix dates to demonstrate follow-through. Regular reviews make it easier to catch an issue that has stayed open too long before the auditor asks about it.
Security review before merge: CC8.1
OpenHack can post security findings directly to GitHub pull requests, including inline comments on affected code. With its merge-blocking review option enabled, findings can trigger a request for changes. Configure GitHub's branch protection to enforce those reviews.
That puts security feedback where developers can act on it. A pull request can bring together the finding, the proposed fix, the review, and the final merge decision. Keep approvals for exceptions alongside the change so the decision is easy to explain later.
Prioritizing real risk: CC3.2
Severity, affected code, dependency paths, and exploit evidence help your team decide what to fix first. A verified authorization bypass in a customer-facing API deserves a different response from an issue with limited exposure.
Use OpenHack's findings to document the technical risk, then add your business context: which system is affected, what data is exposed, and why the team chose that remediation priority.
How to export SAST and Supply Chain reports in OpenHack
Compliance reports are available on OpenHack's Enterprise plans.
For SAST: Open your project, go to Vulnerabilities, and click Export PDF.
For Supply Chain: Go to Supply Chain and click New Scan. Once the scan completes, click Report.
Export the reports for the projects included in your audit and share them alongside your other supporting evidence.
Get ready before the audit
Start scanning and retaining evidence before your examination period begins. Review findings as part of development, keep the fix and retest records, and export reports for the projects in scope. When your auditor asks how you manage application security, you can show the work.
Your SOC 2 examination will also cover policies and processes beyond application security. OpenHack provides supporting security evidence; an independent CPA firm performs the examination and issues the SOC 2 report.
Open OpenHack to scan your project and export your SAST and Supply Chain reports.
