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 built for 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 controls defined, tested, and maintained.
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 which actions are permitted?
- 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.
Configured to customer IT policies. Application settings, hosting boundaries, assessment scope and operational responsibilities are tailored to the security policies and technical requirements of each Automail 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
Snyk scans run automatically every week, checking application source code, direct and transitive dependencies, and Terraform infrastructure configuration.
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
External vulnerability scans use providers such as Intruder to assess internet-facing Automail environments. Scans are performed with each new Automail sub-version upgrade.
Your IT team is welcome to test independently.
We encourage customer security departments to conduct coordinated independent 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. Each customer environment has a separate VPC, container cluster and database. Customer-managed cloud and on-premises deployments are also supported in coordination with the 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 VPC, container cluster and database per customer environment, 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
Supports company-controlled infrastructure, including Windows Server with IIS for Automail hosting and Windows Task Scheduler for scheduled workflows.
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 project.
Every Automail project is maintained as a fork of our core repository. Shared updates can be brought in from upstream, while project-specific configuration stays isolated. Releases then follow a controlled, repeatable path from development to production.
Repository architecture
Shared Automail Core with independently configured project forks
CENTRAL UPSTREAM
Automail Core
One maintained codebase for shared application modules, improvements, and security updates.
Main product repository
ILLUSTRATIVE PROJECT FORKS
Project instance A
Shared core + project/ settings & workflows
Project instance B
Shared core + project/ settings & workflows
Project 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 PROJECT FORK
Development → UAT → Production
Each project 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.
Certification status
Lineverge is not currently SOC 2 or ISO 27001 certified. Security reviews can cover documented engineering controls, assessment procedures and deployment-specific configurations.
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.
ACCESS GOVERNANCE / AUTHORIZATION MODEL
User & group policies
Permissions at every application layer.
Assign access to individual users or groups, then narrow permissions by interface level, operation and data scope.
User / Group
Access scope
01 / MODULE
Module
Application area
02 / PAGE
Page
Module navigation
03 / PANEL
Panel
Page component
04 / ACTION
Action button
Specific operation
Permission gate
Read Write
Rights checked at the applicable scope
DATA-LEVEL AUTHORIZATION
Fine-grained component permissions
Within authorized panels, each table or form applies additional data-access rules.
Writable tables
ROW + COLUMN
Each operation can be controlled at the row and column level for an individual table.
| Operation | Row rules | Column rules |
|---|---|---|
| Read | ||
| Insert | ||
| Update | ||
| Upload | ||
| Download | ||
| Delete |
Configurable for each table component
Drilldown forms
FIELD-LEVEL
Each form presents one table record for detailed review, with save permissions set per field.
Single record
1 row
Field 01 Save
Field 02 Read-only
Field 03 Save
Independent save rules for individual fields
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.
Yes. Automail supports OpenID Connect (OIDC) SSO with a corporate identity provider. Authentication requirements, MFA and password policies are managed by the identity provider. Automatic creation of Automail accounts at first SSO login can be disabled.
When SSO is not enabled, Automail manages authentication at the application level. Password requirements, periodic password changes (including a 90-day policy), failed-login safeguards, account lockout and account deactivation can be configured according to customer IT requirements.
Administrators assign permissions to users and groups, covering modules, pages, panels and actions. Table access can be restricted by operation, row and column; drilldown forms support field-level save permissions. Account provisioning, role changes and deactivation follow the agreed access-management process.
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.
Snyk scans source code, dependencies and infrastructure configurations automatically every week. External vulnerability scans using providers such as Intruder are performed with each new Automail sub-version upgrade. GitHub Security also monitors dependency advisories.
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.
Lineverge is not currently SOC 2 or ISO 27001 certified. IT security assessments can review engineering practices, available scan results and the configuration applicable to the project.
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.