Aligned with your IT policies
Identity, access, network restrictions and security settings are reviewed with the customer's IT team during deployment.
SECURITY & TRUST CENTER AUTOMAIL
Security that stands up to scrutiny.
From access permissions to code scanning and independent testing, our security approach is designed to work with the requirements of enterprise IT teams.
Automail is configured for each deployment. We document controls, review findings, and invite your security team to validate the setup.
OUR APPROACH
Security is an operating practice, not a badge.
Every customer has different IT policies. We combine platform safeguards with deployment-specific configuration, evidence-based reviews, and clear ownership of security findings.
Controls at multiple layers
We address application behavior, underlying infrastructure, software dependencies, and the engineering devices used to maintain them.
Open to independent review
We support customer-run security assessments and use external scanning alongside internal code and configuration checks.
ENTERPRISE CONTROL CHECKLIST
The safeguards IT teams typically ask about.
These controls and practices cover the common areas of a third-party security questionnaire. Some are part of the Automail platform; others are applied or tuned for the individual customer environment.
CONTROL AREA / 01
Identity & permissions
Who can sign in, and what can they do?
- Corporate single sign-on through OIDC, with customer identity-provider policies.
- Local authentication with configurable password rules, including 90-day expiry where required.
- Administrator-managed users and granular application permissions.
- Optional restriction of automatic SSO account creation.
- Access changes and deactivation when responsibilities or employment change.
CONTROL AREA / 02
Application safeguards
Protecting the workflows users interact with.
- Secure coding and review practices aligned with OWASP guidance.
- Server-side validation and controls against common web-application attacks.
- Automatic blocking or lockout after repeated failed login attempts.
- Controls against automated requests and suspicious traffic, including WAF options.
- Authenticated API access with dedicated credentials and permissions.
CONTROL AREA / 03
Visibility & incident response
Knowing what happens and what to do next.
- Application activity and privileged actions recorded for review.
- Operational monitoring and investigation of suspicious access patterns.
- Documented incident classification, escalation and response procedures.
- Access restriction or removal when misuse is identified.
- Customer-specific notification and incident-handling requirements agreed in advance.
CONTROL AREA / 04
Secure software engineering
Security checks beyond the application login.
- Static code analysis and reviews of infrastructure-as-code configurations.
- Dependency vulnerability alerts and automated update pull requests through GitHub Security.
- Targeted scans of direct and transitive software libraries.
- Engineer-owned code review, maintenance and security-oriented refactoring.
- Engineer workstations kept current with operating-system and installed-software updates.
CONTROL AREA / 05
Testing & remediation
Checking controls from an attacker's perspective.
- Internal security scenarios covering authenticated and unauthenticated use.
- External automated vulnerability assessments of exposed services and applications.
- Findings reviewed, prioritized and remediated according to risk.
- Follow-up validation as fixes are implemented.
- Customer IT teams encouraged to run coordinated independent scans and penetration tests.
CONTROL AREA / 06
Infrastructure & data
Hosting choices without losing security oversight.
- Separate customer application environments and restricted administrative access.
- Lineverge-managed AWS by default; customer-managed cloud and on-premises options agreed with IT.
- Encryption and transport-security settings reviewed for each deployment.
- Backup, restoration and recovery expectations agreed with customers.
- Terraform-managed cloud infrastructure with reviewable resource definitions and IaC scanning.
Configuration matters. The exact settings, hosting boundaries, test scope and control owners should be confirmed for each Automail instance. A capability listed here is not a claim that every optional setting is enabled in every deployment.
VULNERABILITY MANAGEMENT
Scan, investigate, remediate, repeat.
We use both automated tooling and targeted application testing. Findings are assessed for severity and addressed through the engineering process, rather than treated as a one-time pass/fail exercise.
Snyk code and configuration scans
Static analysis covers application source, third-party packages (including transitive dependencies), and Terraform infrastructure configuration. A documented review was conducted in March 2026.
GitHub dependency alerts
GitHub Security monitors known package risks and can create automated security notifications and dependency update pull requests for engineering review.
Third-party vulnerability scanning
We have used Intruder to assess an internet-facing Automail test environment. The March 2026 scan produced findings for review and remediation; it is not a certification or penetration-test sign-off.
Your IT team is welcome to test independently.
We encourage customer security departments to conduct their own coordinated vulnerability scans and penetration tests, including authenticated and unauthenticated application scenarios. We review findings with your team and prioritize necessary changes.
CLOUD HOSTING & INFRASTRUCTURE AS CODE
Infrastructure defined in code. Reviewable by your IT team.
Automail is hosted by default in Lineverge-managed AWS, with a separate environment for each customer. Organizations can also choose a customer-managed cloud or an on-premises deployment, in coordination with their IT department.
For our AWS infrastructure, we use Terraform Infrastructure as Code (IaC) to define and manage cloud resources and security configuration. This replaces ad-hoc setup with a repeatable, version-controlled baseline that IT teams can review and scan. Customer-managed environments are adapted to the selected cloud provider and its security requirements.
Infrastructure available for technical review
Customer IT teams can arrange an authorized review of the relevant Terraform source and run infrastructure-as-code security scans. We also use Snyk to check Terraform configurations for potential security issues. Code access, scope and findings are coordinated with your team.
Terraform-managed infrastructure
From versioned definitions to an operating environment
01
Define resources
Infrastructure, networking, access controls and supporting cloud services in code.
02
Review and scan
Examine configuration changes, run IaC checks and align with IT policy.
03
Provision consistently
Apply the agreed configuration to the selected cloud environment.
04
Maintain with oversight
Manage infrastructure updates through reviewable configuration changes.
Customer IT can inspect the applicable infrastructure baseline.
Lineverge-managed AWS
Dedicated customer environments managed by Lineverge, with cloud infrastructure provisioned through Terraform.
Your AWS, Azure or GCP
Deploy within the customer's cloud environment using the applicable provider configuration, permissions and security requirements.
On-premises
Run Automail on company-controlled infrastructure where required, with network access, operations and responsibilities agreed with IT.
Provider-specific Terraform configurations and the split of security responsibilities depend on the deployment. On-premises infrastructure follows the customer's own provisioning and security processes.
VERSION CONTROL & CI/CD
One shared codebase. Controlled releases for every customer.
Every Automail instance is maintained as a fork of our core repository. Shared updates can be brought in from upstream, while customer-specific configuration stays isolated. Releases then follow a controlled, repeatable path from development to production.
Repository architecture
Shared Automail Core with independently configured customer forks
CENTRAL UPSTREAM
Automail Core
One maintained codebase for shared application modules, improvements, and security updates.
Main product repository
ILLUSTRATIVE CUSTOMER FORKS
Customer instance A
Shared core + project/ settings & workflows
Customer instance B
Shared core + project/ settings & workflows
Customer instance ...
Shared core + project/ settings & workflows
Fast upstream updates, preserved customizations. Each fork can fetch and integrate the latest validated Automail changes without rebuilding its project-specific configuration. Changes are reviewed and tested before release.
RELEASE PROCESS / PER CUSTOMER FORK
Development → UAT → Production
Each customer fork uses separate Git branches and environments. Authorized senior Lineverge team members control pushes to the release branches; each UAT or production push automatically triggers its respective deployment pipeline.
master
01 / DEVELOPMENT
Build & test locally
Engineers develop and verify application changes and customer-specific settings using local testing.
uat
02 / USER ACCEPTANCE
Deploy to isolated UAT
A separate, smaller-scale instance with project settings and test data lets business users validate changes before go-live.
prod
03 / LIVE ENVIRONMENT
Release to production
After UAT validation, changes reach the production instance through the automated release pipeline.
Under 2 minutesTypical automated deployment time
Controlled release accessOnly authorized senior team members push release branches
No direct server accessRoutine releases are handled entirely by CI/CD pipelines
DEPLOYMENT & GOVERNANCE
Secure by design. Configured for your environment.
Security requirements are discussed with customer IT before go-live, whether Automail is hosted by Lineverge or deployed in a customer-managed environment.
No certification claim
Lineverge does not currently hold SOC 2 or ISO 27001 certification. We provide information about actual practices, scoped reviews and relevant evidence instead of presenting a certification badge.
Identity and sign-in
Corporate OIDC SSO or controlled local authentication, with password and session requirements defined for the deployment.
Roles and operational access
Agree user responsibilities, administrative permissions, API access, and joiner/mover/leaver procedures.
Hosting and infrastructure
Choose Lineverge-managed AWS, your own cloud or on-premises hosting. Review the applicable Terraform baseline, network boundaries, encryption, backups and operational responsibilities.
Monitoring and review
Align event logging, incident contacts, security-testing windows and follow-up evidence with your IT team's needs.
FOR IT & PROCUREMENT
Answers before your assessment.
A practical starting point for vendor-security questionnaires. Your deployment-specific questions can be covered directly with our engineering team.
Automail supports OIDC SSO with a corporate identity provider. Where local accounts are used, password requirements, periodic changes (including a 90-day policy), and failed-login safeguards can be configured. Identity-provider MFA remains governed by your SSO setup.
Authorized administrators manage access at the application level. User roles and permissions can be tailored to the workflows in scope; account provisioning and prompt deactivation are part of the agreed access-management process. Automatic creation of SSO users can be disabled.
Yes. We encourage scheduled, authorized testing by customer IT or independent specialists. We coordinate scope and timing, assess reported vulnerabilities, and work through remediation and validation with the customer.
No. Scans assess a particular target at a particular time and can identify findings that need attention. We use reports to drive triage and remediation, and provide relevant assessment scope and follow-up information during a security review.
Yes. We use Terraform to define and manage cloud infrastructure, and we review those configurations with security scanning tools such as Snyk. Customer IT can coordinate access to the relevant infrastructure-as-code definitions, review the security baseline and run its own authorized scans. The precise configuration and responsibility split depend on whether Lineverge or the customer operates the environment.
No, not currently. We follow documented, OWASP-aligned engineering and security practices, and support technical reviews and independent validation. A cloud provider's certification does not constitute Lineverge certification.
LET'S REVIEW THE DETAILS
Bring your security team into the conversation.
We can discuss the applicable configuration, testing history, incident procedures, and supporting documentation with qualified IT reviewers. Reports are shared appropriately, with the relevant scope and remediation context.