From f0db6fd6083ab077163cfd51a53f90169396e036 Mon Sep 17 00:00:00 2001 From: Evelyn Date: Wed, 23 Sep 2026 08:43:40 -1200 Subject: [PATCH 1/3] docs: update security policy --- alertdesk/SECURITY.md | 19 +++++-------------- 1 file changed, 5 insertions(+), 14 deletions(-) diff --git a/alertdesk/SECURITY.md b/alertdesk/SECURITY.md index f1ab565..dc1d217 100644 --- a/alertdesk/SECURITY.md +++ b/alertdesk/SECURITY.md @@ -1,29 +1,20 @@ # Security Policy -> **Week 2 task:** Replace the placeholders below with your own policy. -> Delete this callout when you commit the finished file. -## Reporting a vulnerability - +## Reporting a vulnerability -[Describe your reporting process here.] +If you find a vulnerability in the system report it privately to the maintainer, don't share sensitive data publicly ## Authentication (scaffold vs Month 4) - - -[Describe auth handling here.] +Current lab uses stub tokens, proper authentication is planned for Month 4. And tokens are not used outside the lab. ## Database and audit log - - -[Describe data handling here.] +The database stores tickets, and the audit log records actions, and no sensitive secrets go in those logs ## Scope limitations - - -[Describe scope and limitations here.] +This policy applies to the alert desk internship environment. It uses stub tokens for testing only, not for production, and should not be used for real security incidents. \ No newline at end of file From ff34cae3b3302cc100416d35fbe556208b3d8e79 Mon Sep 17 00:00:00 2001 From: Evelyn Date: Mon, 2 Nov 2026 02:42:48 -1200 Subject: [PATCH 2/3] docs: strengthen AlertDesk security policy --- alertdesk/SECURITY.md | 58 ++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 54 insertions(+), 4 deletions(-) diff --git a/alertdesk/SECURITY.md b/alertdesk/SECURITY.md index dc1d217..d1e97ca 100644 --- a/alertdesk/SECURITY.md +++ b/alertdesk/SECURITY.md @@ -4,17 +4,67 @@ ## Reporting a vulnerability -If you find a vulnerability in the system report it privately to the maintainer, don't share sensitive data publicly +If you find a vulnerability in AlertDesk, report it privately to the +maintainer: + + **Name:** George + **Email:** baningeorge@gmail.com + +Do not publicly disclose vulnerabilities or include sensitive information +in public issues. ## Authentication (scaffold vs Month 4) -Current lab uses stub tokens, proper authentication is planned for Month 4. And tokens are not used outside the lab. +The bearer tokens and their associated roles are defined in `config/client-spec.json`. + +These committed bearer tokens are predictable scaffold credentials for testing only. **Never use them outside the internship lab or in production.** They must not be treated as secure credentials or deployed as usable authentication secrets. + +Before any production deployment, replace the stub authentication with a proper authentication mechanism. Proper authentication is planned for Month 4. + + ## Database and audit log -The database stores tickets, and the audit log records actions, and no sensitive secrets go in those logs +AlertDesk stores ticket data in a SQLite database. + +The database location is controlled by the `ALERTDESK_DB` environment variable. If this variable is not set, the application uses `data/alertdesk.sqlite`. + +Security-relevant actions are recorded in the `audit_events` table. Ticket creation, assignment, and status transitions are audited. + +SQLite `BEFORE UPDATE` and `BEFORE DELETE` triggers prevent existing audit records from being modified or deleted through normal database operations. Audit records are therefore append-only under the application's normal database operation. These triggers do not protect against an administrator with direct access to the database file who can alter the schema. + +Audit logs must not contain passwords, bearer tokens, or other sensitive secrets. + +Database backups should be performed regularly according to the deployment environment's backup and recovery requirements. Backups should be stored securely and tested periodically. ## Scope limitations -This policy applies to the alert desk internship environment. It uses stub tokens for testing only, not for production, and should not be used for real security incidents. \ No newline at end of file +This security policy applies to the AlertDesk internship/scaffold +environment. + +AlertDesk is **not a SOAR (Security Orchestration, Automation and +Response) platform or a SIEM (Security Information and Event Management) +platform**. + +The scaffold uses stub tokens for testing only and should not be used +for real security incidents or production security operations. + +The following are outside the current scaffold scope: + + Slack integration + SIEM connectors + SSO + Multi-region operation + +### Known security limitations + +The current internship scaffold has the following security limitations: + +- Authentication uses predictable stub bearer tokens and is not suitable for production. +- Authorization is role-based and limited to the roles and permissions defined in the client specification. +- The application does not currently provide production-grade identity management or single sign-on. +- Audit records are protected against normal SQL updates and deletes through SQLite triggers, but this does not protect against direct database-file or schema manipulation by a privileged user. +- Production-grade monitoring, alerting, backup management, and recovery procedures must be established before production deployment. + +These limitations should be reviewed and addressed before AlertDesk is used in a production security environment. This list is not a complete OWASP compliance assessment. From 2465e404fb32ac7f0886ff797509a1ed93c313b8 Mon Sep 17 00:00:00 2001 From: Evelyn Date: Mon, 2 Nov 2026 11:54:16 -1200 Subject: [PATCH 3/3] docs: correct audit log security description --- alertdesk/SECURITY.md | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/alertdesk/SECURITY.md b/alertdesk/SECURITY.md index d1e97ca..51f3c96 100644 --- a/alertdesk/SECURITY.md +++ b/alertdesk/SECURITY.md @@ -30,14 +30,21 @@ AlertDesk stores ticket data in a SQLite database. The database location is controlled by the `ALERTDESK_DB` environment variable. If this variable is not set, the application uses `data/alertdesk.sqlite`. -Security-relevant actions are recorded in the `audit_events` table. Ticket creation, assignment, and status transitions are audited. -SQLite `BEFORE UPDATE` and `BEFORE DELETE` triggers prevent existing audit records from being modified or deleted through normal database operations. Audit records are therefore append-only under the application's normal database operation. These triggers do not protect against an administrator with direct access to the database file who can alter the schema. + +Audit records are stored in the `audit_events` table. The application +records ticket creation, assignment, and status transitions in the audit +log. However, the current implementation does not enforce append-only +behavior at the database level. Existing audit records can be modified +or deleted by anyone with sufficient SQL write access to the database. + +Production deployments should implement appropriate audit-log integrity +and access controls to prevent unauthorized modification or deletion. + Audit logs must not contain passwords, bearer tokens, or other sensitive secrets. Database backups should be performed regularly according to the deployment environment's backup and recovery requirements. Backups should be stored securely and tested periodically. - ## Scope limitations This security policy applies to the AlertDesk internship/scaffold