Syndacon Security Standards

1. Purpose and Scope

2. Organizational Security

• Least privilege. Access to source code, infrastructure, and Salesforce orgs is granted per person, at the minimum level required. Production systems are a distinct, explicitly guarded boundary (see §3. Secure Development Lifecycle and §4. Salesforce and AgentExchange Standards).
• Multi-factor authentication is required on all accounts with access to source code, cloud infrastructure, and Salesforce orgs.
• Security ownership. A designated security owner is responsible for these standards and participates in design, implementation, and testing decisions. Security is not a phase; it is reviewed continuously as part of every change.
• Credential custody. Credentials and signing keys live only in managed secret stores (the CI platform's secret storage and a dedicated password vault). They are never committed to repositories, embedded in code, or shared through insecure channels. Key material is archived under dated custody records before rotation, and retired only after the replacement is proven working.
• Offboarding. When a person's engagement ends, their access to all systems is revoked and shared credentials within their reach are rotated.

3. Secure Development Lifecycle

All Syndacon code changes, product and infrastructure alike, flow through the same controlled pipeline.

• Version control and protected mainlines. All code lives in version-controlled repositories. Main branches are protected: direct pushes, force pushes, and deletions are blocked; changes land only through reviewed pull requests; stale approvals are dismissed on new pushes; and the protections apply to repository administrators as well. The ability to bypass these gates is restricted to organization and repository owners, and is exercised only rarely, with executive approval, in circumstances where completing the change through the normal gates is impractical.
• Layered review. Every change passes automated static analysis, an automated AI-assisted review against a versioned, checked-in standards document, and human review with required approval. The review standards themselves are code-reviewed artifacts, not tribal knowledge.
• Automated validation gates. A centralized validation pipeline runs linting, formatting, spelling, static analysis, and tests on every change, locally before push and again in CI. Gates are designed to fail closed: a validation run that examines zero files, or a review job that produces no review, is treated as a failure, not a pass. Success must be evidenced, never assumed from silence.
• Static analysis. Salesforce Code Analyzer (including PMD, ESLint, and retire-js engines) runs on all Salesforce source; findings of High or Critical severity block the change. Dependency code is scanned for known vulnerabilities where the platform supports it (via retire-js for JavaScript dependencies). PowerShell tooling is analyzed with PSScriptAnalyzer.
• Testing standards. Every test class provides both unit tests (isolated, mock-injected) and integration tests (real records, real DML). Salesforce tests execute under a non-administrator user context by default, so permission and sharing behavior is exercised rather than bypassed. Every assertion carries a descriptive failure message. Tests are designed to reveal flaws, not to inflate coverage.
• Dependency management. Package managers and runtime versions are pinned; lockfiles are committed; third-party libraries are inventoried through those lockfiles and package manifests, and updated deliberately rather than automatically.
• No production data in development. Development and testing use scratch orgs, sandboxes, and generated test data. Production data is never copied into repositories, test environments, logs, or issue trackers.

4. Salesforce and AgentExchange Standards

Syndacon's Salesforce products are built to the platform's security model and to the requirements of the AgentExchange security review.

• CRUD/FLS and sharing enforcement. Apex that touches user-facing data access enforces object and field-level security (WITH SECURITY_ENFORCED / Security.stripInaccessible / describe checks) and declares its sharing model explicitly. Deliberate system-mode operations are rare, documented, and justified in code.
• Injection prevention. SOQL/SOSL uses bind variables; dynamic query construction from untrusted input is prohibited.
• Client-side security. Lightning Web Components follow the Lightning Locker/LWS security model and platform XSS protections; ESLint runs Salesforce's LWC and Aura security rule sets on all component code.
• No hardcoded identifiers or secrets. Record IDs, org IDs, usernames, endpoints, and credentials are never hardcoded. Secrets used by the application are stored in protected platform storage (Protected Custom Settings/Custom Metadata, Named Credentials).
• Subscriber data stays in the subscriber's org. Syndacon's products run entirely within the customer's Salesforce org, and Syndacon does not extract, transmit, or modify customer org data. Product-specific detail is published in each product's security standards (see Storacle Security Standards).
• Release security gates. Every release candidate passes the full validation pipeline, including Salesforce Code Analyzer scans, before packaging. Promotion of a package to Released status is an explicitly human-approved step. Routine automation builds release candidates, but the irreversible, customer-facing act requires human sign-off.
• CI authentication. Build automation authenticates to Salesforce orgs via certificate-based JWT flows with per-environment credentials that fail closed: a job that does not declare its environment gets no credentials at all, rather than silently inheriting broader access. Deployment environments hold no long-lived secrets beyond the minimum, and the production org's certificate management is deliberately manual.
• Security review. Syndacon's AgentExchange products are submitted to the Salesforce AgentExchange security review, and re-submitted as required for material changes. Scan findings are triaged before submission and false positives are documented.

5. Vulnerability Management

• Continuous scanning. Static analysis runs on every change as described in §3. Secure Development Lifecycle, with dependency vulnerability scanning where the platform supports it; no routine path to production skips them.
• Triage and remediation. Confirmed vulnerabilities are triaged by severity. Critical and High findings block release and are remediated before any new release ships; lower-severity findings are scheduled into normal development work and tracked to closure.
• Reporting a vulnerability. Anyone can report a suspected vulnerability in a Syndacon product or website to security@syndacon.com. Reports are acknowledged promptly, investigated, and the reporter is kept informed of the outcome. Syndacon does not pursue legal action against good-faith security research.

6. Incident Response

Syndacon maintains a documented incident response approach:

1. Identify and assess: determine scope, affected systems, and whether customer data is involved.
2. Contain: revoke or rotate affected credentials, isolate affected systems, and stop ongoing exposure. Credential rotation procedures are documented in advance, including emergency paths that accept service interruption over continued exposure.
3. Eradicate and recover: remove the cause, restore service, and verify integrity before returning to normal operation.
4. Notify: affected customers are notified without undue delay after a confirmed incident involving their data, with what is known, what was done, and what they should do. Where Salesforce platform obligations or applicable law impose specific notification requirements, those govern.
5. Review: every incident ends with a post-incident review; corrective actions are tracked to completion and these standards are updated where the incident exposed a gap.

7. Data Protection

• What Syndacon processes. Syndacon's websites collect contact information voluntarily submitted through forms (name, email address, message content). Customer data in Syndacon's Salesforce products remains in the customer's Salesforce org (see the Storacle Security Standards). Syndacon holds no payment card data.
• Encryption. All Syndacon web properties and service integrations use TLS in transit. Data at rest in Syndacon's hosting and productivity providers is encrypted by those providers (see §8. Third Parties and Subprocessors).
• Storage locations. Syndacon's data is stored with the providers listed in §8. Third Parties and Subprocessors, primarily in United States data centers, on globally distributed edge infrastructure where the provider operates one.
• Retention and deletion. Contact submissions and support correspondence are retained only as long as needed for the purpose they were submitted for, and deleted on verified request.
• Logs. Application and infrastructure logs avoid sensitive data by design; secrets and customer record contents do not belong in logs, alerts, or error messages.

8. Third Parties and Subprocessors

Syndacon relies on a deliberately small set of infrastructure providers:

Customer org data is not shared with any third party (see the Storacle Security Standards). Website contact submissions transit the providers above solely to deliver and respond to them. Third-party software dependencies are inventoried via committed lockfiles and, where the platform supports it, scanned for known vulnerabilities as part of the validation pipeline (see §3. Secure Development Lifecycle).

9. Certifications and Assurance

Syndacon does not currently hold formal certifications such as SOC 2 or ISO 27001. Independent assurance comes from the Salesforce AgentExchange security review (an external, adversarial assessment of the product and Syndacon's security posture), together with the automated scanning and enforced review gates described above. As the company grows, formal certification will be re-evaluated.

10. Review of These Standards

These standards are reviewed at least annually, and whenever an incident, a platform requirement change, or a material change to Syndacon's products or infrastructure warrants it. The "Last updated" date above reflects the most recent revision.