Trust Center · Security

Security

How OpenSource Technologies secures the software we build, the infrastructure we operate, and the engagements we run. Specific controls scoped per engagement and reviewed under your contract's DPA.

Last reviewed: TBD · Pending legal review · OpenSource Technologies, Inc., a Pennsylvania corporation

Draft notice. This document is a structural draft pending legal review. The framework, sections, and OST's general approach are accurate. Specifics (jurisdictions, regulators, exact data-handling language, legal definitions, governing law) are determined per engagement and reviewed by counsel before any production deployment. Use the contact form for engagement-specific compliance questions.

Section 01

Our security commitments

OST builds and operates custom software for clients in regulated, high-trust contexts. Security is engineered into the platform from day one rather than bolted on at audit time.

Our commitments:

Defense in depth: Layered security across infrastructure, application, and operational dimensions
Least privilege: Access granted only to the people and systems that need it
Auditability: Append-only audit logs for sensitive operations, retained per contract
Continuous improvement: Security review on every major release, patch hygiene as standard
Per-engagement scoping: Specific controls calibrated to your data, your regulators, your customers

Section 02

Infrastructure security

OST-operated infrastructure (and infrastructure we deploy on behalf of clients) follows current industry best practices.

Cloud hosting: Major providers (AWS, others per engagement) with hardened configurations
Network security: Private networking, firewalls, and managed access controls
Encryption in transit: TLS 1.2+ for all client-facing and inter-service traffic
Encryption at rest: AES-256 for stored data (databases, file storage, backups)
Patch management: Operating system, runtime, and dependency patching on a defined cadence
Backup and recovery: Continuous backup with disaster-recovery procedures, tested regularly

Section 03

Application security

The software OST builds incorporates security as an engineering practice, not just a deployment concern.

Secure coding standards: OWASP-aligned practices, input validation, output encoding, parameterized queries
Authentication: Strong authentication, MFA where the engagement requires, SSO integration on request
Authorization: Role-based access control, least-privilege enforcement at the application layer
Session management: Secure session handling, idle and absolute timeouts, secure cookies
Dependency management: Tracked dependency inventories, vulnerability scanning, timely updates
Secrets management: Application secrets stored in vaults, not in source control or environment files

Section 04

Operational security

How OST operates the software and infrastructure on a day-to-day basis.

Access control: Engineer access scoped to the engagements they work on, audited regularly
Change management: Code review, automated testing, controlled deploys
Logging and monitoring: Centralized logs, anomaly detection, alert routing for security events
Vulnerability management: Regular scans of OST-operated systems, defined remediation timelines
Personnel security: Background checks where contractually required, security training for engineering staff
Vendor management: Subprocessors evaluated for security posture; see Sub-processors list

Section 05

Compliance frameworks we support

OST does not currently hold SOC 2 or ISO 27001 certification. We engineer toward those frameworks where engagements require, and we support clients in formalizing their own certifications.

Frameworks we have implemented for client engagements:

HIPAA + HITECH: Healthcare engagements where Protected Health Information is in scope. BAA executed at contract.
FERPA + COPPA + SDPC: K-12 and higher education engagements with student data
PCI DSS: Routed through compliant payment processors to minimize cardholder data scope on customer infrastructure
WCAG 2.2 AA + Section 508: Accessibility for federal-grant recipients and consumer platforms
GDPR + UK GDPR: EU and UK data subject rights, processing agreements, transfer mechanisms
CCPA / CPRA + state privacy laws: Right-to-know, right-to-delete, opt-out
Fair Housing Act: Real estate platforms with anti-discrimination requirements
State health-privacy laws (CMIA, etc.): Geography-specific health data requirements

For specific framework requirements on your engagement, contact contact form (Security disclosure or vulnerability report).

Section 06

Incident response

OST maintains an incident response process for security events affecting client engagements.

Detection: Monitoring and alerting surface anomalies; clients can also report issues to contact form (Security disclosure or vulnerability report)
Triage: Severity assessment, scope determination, initial containment
Containment and remediation: Stop ongoing harm, remove the threat, restore normal operations
Notification: Per contractual and legal obligations (typically 72 hours for confirmed breaches under most frameworks)
Post-incident review: Root cause analysis, corrective action, documentation

Notification timelines, formats, and recipients are determined by the engagement contract, the data protection agreement, and applicable law (e.g., GDPR Article 33, state breach-notification statutes).

Section 07

Reporting a security issue

If you have discovered a security vulnerability in any OST-built or OST-operated platform:

Email: contact form (Security disclosure or vulnerability report)
Include: a description of the issue, steps to reproduce, the affected platform or domain, and your contact information
OST acknowledges security reports within 1 business day and provides a remediation timeline within 5 business days

OST appreciates responsible disclosure and will work in good faith with researchers who report issues responsibly. Public disclosure should be coordinated with OST and the affected client.