Resilience
/
wp2-be-audit-bs
18
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Added SECURITY and CODE_OF_CONDUCT files

This commit is contained in:
Vishal Raut 2026-03-17 15:04:25 +05:30
parent bc3ecca8a6
commit 0b17f88034
2 changed files with 211 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

106
CODE_OF_CONDUCT_HORTUS.md Normal file
View File

@ -0,0 +1,106 @@
# Code of Conduct
| Field | Value |
|---|---|
| Project | ITSERR HORTUS |
| Document | Community Code of Conduct |
| Version | 1.0 |
| Status | Proposed |
| Last updated | 2026-03-05 |
## Purpose
HORTUS is a collaborative environment for researchers, contributors, maintainers, editors, support staff, designers, testers, and community members working across software, documentation, events, training, discussions, messaging, and issue tracking.
This Code of Conduct exists to keep those spaces respectful, inclusive, constructive, and safe.
## Our Commitment
We want participation in the HORTUS community to be welcoming and professionally respectful for everyone, regardless of age, disability, ethnicity, nationality, language, religion, belief, sex characteristics, gender identity or expression, sexual orientation, level of experience, socio-economic status, appearance, or disciplinary background.
Because HORTUS serves Religious Studies and related fields, we also expect care when discussing traditions, communities, beliefs, and sensitive research topics.
## Expected Behaviour
Examples of expected behaviour include:
- using respectful, inclusive language;
- debating ideas rigorously without attacking people;
- giving constructive, specific feedback;
- being open to correction and different perspectives;
- acknowledging others' time, labour, and expertise;
- respecting privacy, consent, attribution, and intellectual property;
- reporting problems through the appropriate support, moderation, or security channels.
## Unacceptable Behaviour
Unacceptable behaviour includes, but is not limited to:
- harassment, intimidation, stalking, or threats;
- hateful, discriminatory, or demeaning language or imagery;
- personal attacks, insults, or bad-faith provocation;
- trolling, flaming, or deliberately disruptive behaviour;
- publishing or soliciting private, confidential, or personal data without permission;
- sexualized language, unwanted sexual attention, or unwelcome advances;
- doxxing, impersonation, or deceptive identity claims;
- retaliating against someone who reports a concern;
- spamming support, issue, discussion, messaging, or event spaces;
- ridiculing individuals or communities on the basis of religion, belief, ethnicity, gender, sexuality, disability, or other protected characteristics.
## Scope
This Code of Conduct applies to:
- repository issues, pull requests, reviews, commits, and discussions;
- documentation, examples, and knowledge-base content;
- HORTUS collaboration spaces such as messaging, comments, forums, support tickets, training spaces, and event-related interactions;
- public or private interactions where someone is representing the HORTUS project or community.
## Reporting Concerns
If you experience or witness behaviour that violates this Code of Conduct:
- report it to the repository maintainers or the HORTUS support / ticketing channel;
- use a private reporting path when possible, especially if personal safety or privacy is involved;
- include links, screenshots, timestamps, or other context that helps with review.
Reports will be handled as confidentially as reasonably possible.
If the report concerns a security issue rather than community behaviour, use the private path described in `SECURITY_HORTUS.md`.
## Enforcement
Project maintainers and moderators are responsible for interpreting and enforcing this Code of Conduct.
They may take any action they judge appropriate, including:
- requesting a change in behaviour;
- editing, hiding, locking, or removing content;
- rejecting contributions;
- suspending access to a repository or community space;
- temporarily or permanently banning a participant from HORTUS-managed spaces;
- escalating serious matters through the relevant operational or governance channels.
## Good Community Practice
Before escalating conflict, community members are encouraged to:
- assume confusion before malice when the facts support that reading;
- ask clarifying questions;
- move heated exchanges out of public threads when a moderator requests it;
- keep criticism focused on content, evidence, and implementation rather than on people.
## Attribution
This document is informed by open-source community governance practices, including the Contributor Covenant, and adapted for the ITSERR HORTUS research and collaboration context.
## Related Repository Documents
- `CONTRIBUTING_HORTUS.md`
- `SECURITY_HORTUS.md`
## Change Log
| Version | Date | Summary |
|---|---|---|
| 1.0 | 2026-03-05 | Initial HORTUS-specific code of conduct aligned to RS015-derived community governance needs. |

105
SECURITY_HORTUS.md Normal file
View File

@ -0,0 +1,105 @@
# Security Policy
| Field | Value |
|---|---|
| Project | ITSERR HORTUS |
| Document | Repository Security Policy |
| Version | 1.0 |
| Status | Proposed |
| Last updated | 2026-03-05 |
## Purpose
This policy explains how to report security vulnerabilities affecting the ITSERR HORTUS codebase, documentation, and repository-managed integrations.
HORTUS is a web-based research platform for Religious Studies built around catalog, workspace, collaboration, support, training, expert discovery, and metadata services. The repository may include code and documentation related to features such as authentication and authorization, profile management, metadata workflows, document parsing, notifications, messaging, support, ORCID/DOI integrations, and interoperability with external systems.
This policy complements the operational and infrastructure processes used for hosted HORTUS services. If a reported issue affects a D4Science-managed service or another integrated external provider, the HORTUS maintainers should coordinate the escalation with the relevant operator.
## Supported Releases
Security fixes are prioritized for:
- the default development branch;
- the latest production-supported tagged release;
- any additional branch or release explicitly marked by maintainers as supported.
Older, archived, experimental, or unsupported branches may not receive security fixes.
## Report a Vulnerability
Do **not** open a public issue for a suspected security vulnerability.
Use one of the following private reporting paths:
1. the repository platform's private vulnerability reporting feature, if enabled;
2. a confidential ticket through the HORTUS Support / Issues service;
3. a direct non-public contact path maintained by the repository maintainers.
If you are unsure whether something is a security issue, report it privately first.
## What to Include in a Report
Please include as much of the following as possible:
- affected component, module, page, endpoint, workflow, or integration;
- clear reproduction steps;
- expected behavior and actual behavior;
- potential impact on confidentiality, integrity, availability, privacy, or authorization;
- screenshots, logs, stack traces, or payload examples that help reproduce the issue;
- affected versions, branch names, commit hashes, browsers, operating systems, or environments;
- whether the issue involves personal data, authentication tokens, or role and permission boundaries.
Please **sanitize** any logs or evidence before sharing them. Do not send live credentials, secrets, private keys, or unnecessary personal data.
## Typical Security Scope
Examples of issues that should be reported under this policy include:
- authentication or authorization flaws;
- RBAC or membership bypasses;
- privacy leaks involving profile data, uploaded content, metadata, messages, or notifications;
- insecure file upload, parsing, export, import, or sharing workflows;
- injection, XSS, CSRF, SSRF, path traversal, insecure deserialization, or similar classes of issues;
- unsafe integration behavior involving ORCID, DOI services, Zenodo, Zotero, or other external systems;
- dependency vulnerabilities that materially affect HORTUS;
- exposure of secrets, tokens, configuration, or environment data;
- insecure default settings or missing security checks in CI/CD, APIs, or deployment automation.
If an issue is located in an external service but has a material security effect on HORTUS users or data, please still report it privately so it can be routed correctly.
## Coordinated Handling
After a report is received, maintainers should:
- validate and triage the issue;
- assess severity and affected scope;
- coordinate remediation with the appropriate maintainers, operators, or integration owners;
- prepare a fix, mitigation, or temporary workaround;
- publish a disclosure note when it is safe to do so.
No public disclosure should be made before a reasonable mitigation path is in place.
## Good-Faith Research
Good-faith security research is welcome. Please:
- avoid privacy violations, destructive testing, denial-of-service activity, or social engineering;
- avoid modifying or deleting data that does not belong to you;
- stop testing and report immediately if you discover sensitive data exposure;
- keep findings confidential until maintainers confirm that disclosure is safe.
## Non-Security Bugs
For functional bugs, usability problems, documentation defects, feature requests, or support questions, use the standard repository issue tracker or the HORTUS Support / Issues workflow.
## Related Repository Documents
- `CONTRIBUTING_HORTUS.md`
- `CODE_OF_CONDUCT_HORTUS.md`
## Change Log
| Version | Date | Summary |
|---|---|---|
| 1.0 | 2026-03-05 | Initial HORTUS-specific security policy aligned to RS015-derived repository needs. |