Security Posture and Vulnerability Reporting

Security philosophy

Reduce unnecessary attack surface and keep trust boundaries explicit

Evulgare's packaged architecture favors first-party delivery, bounded dependencies, environment-supplied secrets, explicit public/private separation, constrained public inputs, and evidence-preserving release operations. Higher-consequence paths should fail closed when required authority, configuration, or evidence is absent.

Security is not established by a slogan, one header, or one passing test. Repository controls describe the software package. They do not independently prove production firewall state, hosting configuration, operator practice, patch level, monitoring, incident handling, or the security of a third-party service.

Public-site architecture

Controls visible in the packaged source

These statements describe repository implementation and configuration defaults. Actual-host verification is required before they are treated as current production facts.

01

First-party assets

Public templates load repository-owned styles, scripts, images, fonts, and same-origin endpoints. No third-party analytics or embedded runtime widget is declared.

02

Restrictive browser policy

The application emits a content security policy that limits scripts, styles, forms, connections, fonts, and frames, with nonces for permitted inline scripts.

03

Browser form integrity

Public HTML forms and private administration use CSRF controls. Stateless public JSON simulation endpoints are explicitly separated from that browser-session contract.

04

Private administration

No public signup exists. Repository code includes role-based private administration, Argon2id password hashing, login throttling, secure-cookie settings, and no-store responses.

05

Production configuration gates

The application refuses production startup when the secret, MySQL URL, secure-cookie setting, or HTTPS base URL does not satisfy the declared configuration contract.

06

Release integrity

Versioned packages include manifests, hashes, file inventories, release identity, runtime-integrity records, and clean-extraction verification within their stated scope.

07

Bounded dependencies

Runtime dependencies are listed explicitly with version ranges for the supported Python runtime instead of relying on undeclared packages.

08

Input boundaries

Public workbenches reject credentials, protected strategy, arbitrary uploads or URLs, classified material, real target data, force authorization, and operational commands.

Submission safety

What visitors should never send through public channels

The public contact form and public workbenches are not privileged security systems. A security report should use the minimum proof needed to identify the issue and potential impact.

Do not provide live operational access, attempt to demonstrate impact against unrelated data, or include protected material when a description and bounded reproduction are sufficient.

Never submit

Passwords, API keys, access tokens, authentication cookies, recovery codes, or session material
Private keys, signing keys, certificate private material, or production secrets
Classified information, controlled technical data, target data, or live operational records
Customer content, regulated records, unrelated personal information, or data obtained without authority
Persistent access mechanisms, destructive payloads, denial-of-service traffic, or proof beyond what is necessary
Weapon, vehicle, force-authorization, or external execution commands

Responsible disclosure

Reporting a suspected vulnerability

The only verified public contact route is the first-party form. Select “Security reports.” If the issue can be explained safely, provide the affected public URL or component, reproducible steps, expected versus observed behavior, potential impact, and the minimum non-sensitive proof needed to demonstrate the problem.

Do not exploit beyond what is necessary to demonstrate the issue. Do not access, modify, retain, or disclose data that is not yours; do not establish persistence; do not degrade service; and do not test third-party systems merely because they are linked from Evulgare.

If the detail itself would expose a credential, private key, protected infrastructure, personal data, or a weaponizable exploit, do not place that detail in the ordinary form. Submit a high-level description and request a safer coordination path. The current repository does not establish that such a path or a response-time commitment is available.

Route a security report

Useful report structure

01
Affected surfacePublic URL, route, release, component, or file.
02
ReproductionMinimal steps using data and systems you are authorized to test.
03
Expected / observedState the intended behavior and the behavior you observed.
04
Potential impactExplain the bounded consequence without overstating certainty.
05
Minimal proofRedact secrets and include only what is necessary to establish the issue.

Scope boundaries

What the public page cannot establish

The repository cannot independently establish the current state of every production server, database, network control, DNS record, TLS endpoint, cPanel process, hosting provider, monitoring service, backup, credential store, operator workstation, or linked external site.

Release hashes establish byte identity only for the files and algorithm named in the record. Browser security headers describe application responses produced by the packaged code; reverse proxies or host configuration can add, remove, or alter headers. A clean source review is not a penetration test, and an automated check is not a security certification.

Repository controls: ESTABLISHED IN SOURCECode and configuration can be inspected in the identified package.
Release byte identity: ESTABLISHED WITHIN HASH SCOPEHashes and manifests support file identity for the named artifacts.
Current production state: NOT ESTABLISHED HEREActual-host observation is required for server, network, database, and deployment claims.
Penetration test: NOT CLAIMEDNo current third-party penetration-test result is represented by this page.
Certification or audit: NOT CLAIMEDNo SOC 2, ISO, FedRAMP, or equivalent certification is asserted.

Security evidence

Inspect release and integrity records without overextending them

Evulgare publishes release identity, runtime-integrity, manifest, verification, and implementation records for the package. These records can support review of source completeness, file identity, test scope, and stated acceptance boundaries.

They do not prove that a production host is running the same release unless a separate server-owned observation binds that host, runtime, root, and build identity to the package.

Release identity record → Release identity proof → Documentation directory → Privacy and public-site data practices →

Evidence and change history

Inspect the claims behind Security

Review claim class, support status, source identity, observation environment, scope, limitations, known defeaters, and append-oriented change events. The ledger does not convert a repository statement or target into deployment, certification, compliance, or external validation.

Open Security evidence