Public edge
TLS termination, managed request filtering, rate limits, and health-aware routing.
Skip to content
01
02
03
04
01
02
03
04
05
Security and trust
Protection that can be examined.
Project X IT is building the platform around server-side authorization, tenant isolation, encryption, traceable evidence, secure development, and explicit production acceptance gates.
TransportModern TLS at the public edge
IdentityServer-enforced authorization and MFA gates
Tenant dataSeparated customer data and key boundaries
Pilot boundarySynthetic demonstration data only
Customer data boundary
A browser request does not choose its own customer.
Authentication, tenant membership, role, data access, imports, and connector actions are validated by the server. Client-side code is treated as untrusted presentation logic.
IdentityPasswords are protected server-side, MFA is enrolled through account settings, and sensitive operations require an authenticated account that satisfies the applicable readiness gates.
AuthorizationEvery protected operation checks the authenticated membership, role, tenant, and requested action rather than accepting a browser-provided authorization decision.
EncryptionCustomer evidence is designed for encryption in transit and at rest, with tenant-specific data-key separation and infrastructure encryption beneath it.
ConnectorsProvider credentials, token exchange, refresh, revocation, validation, and imports remain server-side and are scoped to the authorized tenant.
EvidenceSecurity, administrative, connector, import, and change events are designed to retain accountable ownership and investigation context without logging secrets.
Layered architecture
Public explanation outside. Isolated evidence workspaces inside.
The public site contains marketing and trust information. Customer functions, identities, evidence, reports, and administrative workflows remain behind the authenticated application boundary.
Private runtime
Non-root application workloads with no direct public address and server-side request controls.
Tenant broker
Authenticated tenant routing, role enforcement, key references, and dedicated connection boundaries.
Customer data plane
Production design for a separate PostgreSQL database, credentials, key context, objects, and backups per customer.
Common control model
Implement the operating discipline once and map the evidence where it applies.
The platform organizes security outcomes across governance, identification, protection, detection, response, and recovery while preserving framework-specific requirements and limitations.
Governance and ownership
Policy, responsibility, oversight, staffing, adherence, risk decisions, and accountable approval.
Identity and access
Lifecycle, MFA, least privilege, service identities, authorization, and separation of duties.
Assets, data, and configuration
Inventory, classification, approved state, industry standards, exceptions, and verified remediation.
Detection and response
Logging, monitoring, anomaly detection, incident analysis, escalation, and communication.
Continuity and recovery
BIA, CFO-approved MTD, RTO, RPO, dependencies, backups, restoration, and exercises.
Assessment and improvement
Evidence, testing, deficiencies, corrective action, retest, owner review, and continuous monitoring.
Control mappings support preparation and evidence organization. They do not represent certification, an auditor's opinion, automatic compliance, or legal advice.
Secure development lifecycle
Testing is a release input, not a badge.
Security evidence is tied to the build, target, date, scope, tool, and stated limitations. Findings are tracked through remediation, retest, or documented risk decisions.
Design
Threat boundaries, data classification, abuse cases, privacy, authorization, and recovery requirements.
Build
Reviewed changes, supported dependencies, secret controls, deterministic artifacts, and least-privilege runtime configuration.
Verify
Unit, integration, tenant-isolation, SAST, dependency, container, infrastructure, parser, and DAST checks.
Release
Commit-bound deployment, promotion gates, health checks, rollback, and retained release evidence.
Monitor
Authentication, application, cloud, connector, key, administrative, and change-detection signals.
Assurance evidence
Reports must be current, scoped, and honest about their limits.
Project X IT maintains build-specific SAST, DAST, dependency, architecture, and control evidence for internal review and controlled customer due diligence. Public reports will be published only when the artifact matches the identified release and omits details that would increase attack value.
Static analysis
Source patterns, authorization boundaries, input handling, secret exposure, and coding defects are reviewed with finding dispositions.
Dynamic analysis
Authorized targets are tested for transport, headers, session behavior, public-route exposure, denial behavior, and web vulnerabilities.
Build and dependencies
Runtime support, production dependencies, container and infrastructure configuration, automated tests, and release identity are recorded.