Security engineering / Practical guide
Secure software engineering: examples from our own systems
Our defensive security work starts with software we build and operate. The examples below describe application controls, regression tests and release checks in our own website and support systems. They also explain the boundary between infrastructure assessment and an approved production change.
Staff access must follow current permissions
Our support workspace connects staff through the CRM identity and permission system. The sign-in exchange binds a short-lived challenge to the requesting browser and expected origin. Staff actions check current CRM rights rather than treating an earlier sign-in as permanent permission.
Automated tests exercise invalid signatures, a different browser or origin, expired challenges, repeated proofs and revoked staff access. They also check that anonymous visitors cannot enter staff APIs. The regression scenarios use synthetic accounts and controlled browser sessions.
- Browser-bound sign-in challenges
- Request-origin and CSRF validation
- Permission revocation and session expiry
- Rejected anonymous access to staff operations
Reduce sensitive information entering support chat
The website assistant checks input for recognised credentials and sensitive material, including private keys, connection strings and verification codes. File attachments are unsupported. Tests cover several credential formats, disguised text and requests to submit private files, while allowing ordinary troubleshooting questions and explicitly redacted examples.
Internal staff notes are excluded from the tested AI-draft input. These checks reduce exposure; they cannot recognise every possible secret. Users should never paste credentials or private records into chat. An automated draft still requires a staff decision before it becomes a customer response.
- Recognised credential and private-file input rejection
- Redacted examples for troubleshooting
- Bounded conversation context
- Staff review of generated reply drafts
Bound work before it reaches an external system
Our website engineering includes request-admission limits, bounded identity tracking, queue limits and duplicate handling. Security tests check that excess requests are rejected before creating durable work or making a provider call, and that admitted requests retain their receipts.
The same test area checks CSRF validation for cart changes and access to order-recovery receipts. The checks use controlled environments to verify application behaviour before a change is accepted.
Keep infrastructure assessment separate from change
DomainOps Studio is our Active Directory and Windows infrastructure assessment project. Its demonstrated scope is read-only discovery, reports and planning evidence. Evaluation must identify the systems included, the permissions needed and the sensitive information a report can contain.
Assessment output supports an operator’s decision. Migration, recovery and production writes require a separately agreed scope and change approval.
Use findings to improve the software
Our intended use of advanced AI security tooling is internal defensive work: reviewing our own source, identifying trust-boundary weaknesses, investigating suspected defects in isolated environments and checking a proposed fix. A model suggestion is a lead to investigate, not a confirmed vulnerability.
Access to a third-party environment requires explicit authorisation and an agreed scope. Approval for an internal AI workflow does not authorise a customer-facing security service or the transfer of customer code to a provider.
- Define the owned system, data and permitted actions.
- Reproduce a suspected defect with synthetic or redacted inputs.
- Review and implement the fix, then rerun the affected checks.
- Record version, environment, results and remaining limits before release.
Read the evidence at its actual scope
These examples describe first-party engineering checks for specific versions and environments. We record local test results separately from deployment verification and customer acceptance, so a reviewer can see exactly what has been demonstrated.
For a security concern involving a Softwexa system, start with [email protected] and provide the affected public URL, a non-sensitive description and your contact details. Do not include passwords, tokens, private customer records or exploit payloads in an initial message.
Primary sources
Sources and further reading.
These platform references support the technical guidance. Available features, versions and implementation requirements should be checked against your environment.