timetracker

遵循以下最佳实践的项目将能够自愿的自我认证，并显示他们已经实现了核心基础设施计划（OpenSSF）徽章。

没有一套可以保证软件永远不会有缺陷或漏洞的做法；如果规范或假设是错误的，即使合适的方法也可能失败。也没有哪些做法可以保证一个项目能够维持健康和运作良好的开发者社区。但是，遵循最佳做法可以帮助改善项目的成果。例如，一些做法可以在发布之前进行多人评估，这可以帮助您找到其他难以找到的技术漏洞，并帮助建立信任，并希望不同公司的开发人员之间进行重复的交互。要获得徽章，必须满足所有“必须”和“禁止”的条款，满足所有“应该”条款或有合适的理由，和所有“建议”条款必须满足或未满足（至少希望考虑）。欢迎通过 GitHub网站创建问题或提出请求进行反馈。另外还有一个一般讨论邮件列表。

如果这是您的项目，请在项目页面上显示您的基准徽章状态！基准徽章状态如下所示： 项目11719的基准徽章等级为baseline-2 以下是如何嵌入基准徽章：
您可以通过将其嵌入到Markdown文件中来显示您的基准徽章状态：
[![OpenSSF Baseline](https://www.bestpractices.dev/projects/11719/baseline)](https://www.bestpractices.dev/projects/11719)
或者将其嵌入到HTML中：
<a href="https://www.bestpractices.dev/projects/11719"><img src="https://www.bestpractices.dev/projects/11719/baseline"></a>


这些是基准等级3的标准。 这些是标准版本 v2026.08.28。

Baseline Series: 基准等级1 基准等级2 基准等级3

        

 基本

  • 常规

    请注意，其他项目可能使用相同的名称。

    Simple time tracking front end with optional Jira synchronization, AD/LDAP integration and XLSX export.

    请使用 SPDX许可证表达格式;例子包括“Apache-2.0”，“BSD-2-Clause”，“BSD-3-Clause”，“GPL-2.0+”，“LGPL-3.0 +”，“MIT”和“(BSD-2-Clause OR Ruby)”。
    如果有多种语言，请将它们列为逗号分隔值（可选空格），并将它们从最多到最少使用。如果有长列表，请至少列出前三个最常见的列表。如果没有语言（例如，这是仅文档或仅测试项目），请使用单个字符“ - ”。请使用每种语言的常规大小写，例如“JavaScript”。
    通用平台枚举（CPE）是用于信息技术系统，软件和软件包的结构化命名方案。在报告漏洞时，它可用于多个系统和数据库。

 控制 15/21 ●

  • 控制


    足够获得徽章！

    当在CI/CD管道中为作业分配权限时，源代码或配置必须仅分配相应活动所需的最低权限。 [OSPS-AC-04.02]
    配置项目的CI/CD流水线，默认为用户和服务分配最低可用权限，仅在特定任务需要时才提升权限。在某些版本控制系统中，这可以在组织或代码仓库级别实现。如果不行，请在流水线的顶层设置权限。

    Every workflow declares an explicit minimal permissions block: ci.yml, codeql.yml, security.yml, scorecard.yml and auto-merge-deps.yml use permissions: {} or contents: read, and elevated scopes are granted only where the activity requires them (packages: write and id-token: write for image publishing, contents: write and id-token: write for release provenance). See https://github.com/netresearch/timetracker/tree/main/.github/workflows


    足够获得徽章！

    接受可信协作者输入的 CI/CD 流水线在流水线中使用该输入之前，必须对其进行清理和验证。 [OSPS-BR-01.04]
    CI/CD 流水线应对显式工作流执行中的所有协作者输入进行清理（引用、转义或在期望值时退出）。虽然协作者通常是可信的，但工作流的手动输入无法经过审查，可能被账户劫持或内部威胁所滥用。

    No workflow interpolates collaborator-supplied values into shell commands; workflow_dispatch triggers declare no free-text inputs, and all run steps use fixed strings or environment variables. OpenSSF Scorecard's Dangerous-Workflow check scores 10/10. See https://securityscorecards.dev/viewer/?uri=github.com/netresearch/timetracker


    足够获得徽章！

    当创建正式发布版本时，该发布版本中的所有资产必须明确关联到发布标识符或资产的其他唯一标识符。 [OSPS-BR-02.02]
    为项目生成的每个软件资产分配唯一的版本标识符，遵循一致的命名约定或编号方案。示例包括SemVer、CalVer或git提交ID。

    Releases carry no separate downloadable assets; the released artifact is the container image, which is tagged from the release tag via docker/metadata-action semver patterns (for example 6.3.4, 6.3, 6) and is additionally addressable by immutable digest on ghcr.io. See https://github.com/netresearch/timetracker/blob/main/.github/workflows/docker-publish.yml


    足够获得徽章！

    项目必须定义管理项目使用的秘密和凭证的策略。该策略应包括存储、访问和轮换秘密和凭证的指南。 [OSPS-BR-07.02]
    记录项目内如何管理和使用秘密和凭证。这应包括如何存储秘密（例如，使用秘密管理工具）、如何控制访问以及如何轮换或更新秘密的详细信息。确保敏感信息不会硬编码在源代码中或存储在版本控制系统中。

    docs/secrets-management.md defines the policy across all three dimensions. Storage: a table of secret kinds and their stores (GitHub Actions secrets, GITHUB_TOKEN, keyless Sigstore, Vault, .env.local). Access: fork pull requests receive no secrets, and every secret has a named owner. Rotation: a trigger table including rotation within five working days when someone with access leaves, and at least annually for every long-lived credential. See https://github.com/netresearch/timetracker/blob/main/docs/secrets-management.md


    足够获得徽章！

    当项目已发布版本时，项目文档必须包含验证发布资产完整性和真实性的说明。 [OSPS-DO-03.01]
    项目中的说明应包含所使用技术、要运行的命令以及预期输出的信息。如果可能，避免将此文档存储在构建和发布流水线的相同位置，以避免单一漏洞同时危及软件和验证软件完整性的文档。

    SECURITY.md carries a 'Verifying a release' section with runnable commands: sha256sum -c against the published checksum, 'gh attestation verify' for the source archive, 'cosign verify' for the image and 'cosign verify-attestation --type cyclonedx' for its SBOM. The certificate-identity patterns are anchored to the specific signing workflows, and the section warns explicitly against loosening them to the organisation prefix, which would accept a certificate from any workflow in the org. It also notes that the commands signal failure by exit status rather than output. See https://github.com/netresearch/timetracker/blob/main/SECURITY.md


    足够获得徽章！

    当项目已发布版本时，项目文档必须包含验证软件发布作者的预期身份的说明。 [OSPS-DO-03.02]
    预期身份可能采用用于签名的密钥ID、来自sigstore证书的颁发者和身份或其他类似形式。如果可能，避免将此文档存储在构建和发布流水线的相同位置，以避免单一漏洞同时危及软件和验证软件完整性的文档。

    The same section identifies the expected signer and how it changes. Releases up to v6.4.0 were signed by this repository's own workflow and verify with '--repo' alone; from the first release after v6.4.0 the attestation is issued by a reusable workflow in netresearch/.github, so verification requires '--signer-workflow netresearch/.github/.github/workflows/attest-release-files.yml'. Both forms are documented with the boundary stated, and AGENTS.md records the same for maintainers. See https://github.com/netresearch/timetracker/blob/main/SECURITY.md


    足够获得徽章！

    当项目已发布版本时，项目文档必须包含关于每个发布版本支持范围和持续时间的描述性声明。 [OSPS-DO-04.01]
    为了传达项目发布的软件资产的支持范围和持续时间，项目应有SUPPORT.md文件、SECURITY.md中的"支持"部分或其他文档，说明支持生命周期，包括每个发布版本的预期支持持续时间、提供的支持类型（例如，错误修复、安全更新）以及获取支持的任何相关策略或程序。

    SECURITY.md states the support policy explicitly: only the current minor line receives fixes, and a new minor release ends support for the previous one. The supported-versions table carries an End-of-life column, currently listing 6.3.x as supported until 6.4.0 is released. It also records that there are no long-term-support branches. See https://github.com/netresearch/timetracker/blob/main/SECURITY.md


    足够获得徽章！

    当项目已发布版本时，项目文档必须提供描述性声明说明何时发布版本或版本将不再接收安全更新。 [OSPS-DO-05.01]
    为了传达安全修复的支持范围和持续时间，项目应有SUPPORT.md或其他文档，说明项目的安全更新策略。

    SECURITY.md gives end-of-support statements per release line in a dedicated End-of-life column: 6.3.x ends when 6.4.0 is released, 6.0.x to 6.2.x were superseded by the following minor, and 5.x reached end of life on 2026-07-04 with the release of v6.0.0. Security fixes are explicitly not backported. See https://github.com/netresearch/timetracker/blob/main/SECURITY.md


    不足以获得徽章。

    项目文档必须制定一项政策，规定在向代码协作者授予提升权限以访问敏感资源之前对其进行审核。 [OSPS-GV-04.01]
    在项目文档中发布可执行的策略，要求在授予对敏感资源（例如合并批准或访问秘密）的提升权限之前审查和批准代码协作者。建议审查包括建立可证明的身份血统，例如确认贡献者与已知可信组织的关联。

    The project documentation contains no policy for reviewing code collaborators before granting escalated permissions to sensitive resources. Access is managed through Netresearch GitHub organization teams, but the review step is not written down. Documenting it is planned.


    足够获得徽章！

    当项目已发布版本时，所有编译的已发布软件资产必须附带软件物料清单。 [OSPS-QA-02.02]
    建议在构建时使用经过准确性审查的工具自动生成SBOM。这使用户能够以标准化的方式将此数据与其环境中的其他项目一起提取。

    Published container images carry a software bill of materials. The image build produces an in-image SBOM attestation via buildx and a merged CycloneDX SBOM (composer.lock plus a Syft scan of the pushed digest), attached to the image digest as a Cosign attestation and uploaded as a workflow artifact; a separate attest-sbom job records a GitHub build attestation. See https://github.com/netresearch/timetracker/blob/main/.github/workflows/docker-publish.yml


    足够获得徽章！

    当项目已发布包含多个源代码仓库的版本时，所有子项目必须执行与主代码库一样严格或更严格的安全要求。 [OSPS-QA-04.02]
    项目生成并编译到发布版本中的任何其他子项目代码仓库必须根据相应代码库的状态和意图执行安全要求。除了遵循相应的OSPS基线要求外，这还可能包括要求进行安全审查、确保其没有漏洞以及确保其没有已知的安全问题。

    The project consists of a single source code repository; there are no subprojects to hold to the primary codebase's security requirements. See https://github.com/netresearch/timetracker


    足够获得徽章！

    项目文档必须清楚地记录测试的运行时间和方式。 [OSPS-QA-06.02]
    在贡献文档中添加一个章节，说明如何在本地运行测试以及如何在CI/CD管道中运行测试。文档应说明测试的测试内容以及如何解释测试结果。

    docs/testing.md documents the test layers and how to run them, CONTRIBUTING.md states the testing requirements, the Makefile exposes the standard test targets, and .github/workflows/ci.yml defines when each suite runs (every pull request and push, with coverage on the nightly schedule). See https://github.com/netresearch/timetracker/blob/main/docs/testing.md


    足够获得徽章！

    项目文档必须包含一项政策，规定对项目生成的软件所做的所有重大更改都应在自动化测试套件中添加或更新相应功能的测试。 [OSPS-QA-06.03]
    在贡献文档中添加一个章节，说明添加或更新测试的政策。该政策应说明什么是重大更改以及应该添加或更新哪些测试。

    CONTRIBUTING.md requires tests for new and changed functionality and states per-layer coverage expectations (controllers, services, repositories, entities), with the author and reviewer checklists calling out test coverage explicitly. See https://github.com/netresearch/timetracker/blob/main/CONTRIBUTING.md


    不足以获得徽章。

    当向主分支提交时，项目的版本控制系统必须在合并之前要求至少一名非作者人工审批更改。 [OSPS-QA-07.01]
    配置项目的版本控制系统，要求在合并到发布分支或主分支之前至少有一名非作者人工审批更改。这可以通过要求拉取请求在合并之前必须由至少另一位协作者审查和批准来实现。

    The branch protection rule on 'main' does not require approving reviews - 'Require a pull request before merging' is disabled and no required_approving_review_count is configured - so a change can reach main without any non-author human approval. Note that CONTRIBUTING.md currently claims '2+ approvals from maintainers'; that claim does not match the enforced configuration and is being corrected. Verified in branch protection settings on 2026-09-18.


    足够获得徽章！

    当项目发布版本时，项目必须执行威胁建模和攻击面分析，以理解和防护针对系统内关键代码路径、函数和交互的攻击。 [OSPS-SA-03.02]
    威胁建模是一项活动，其中项目查看代码库、相关流程和基础设施、接口、关键组件，并"像黑客一样思考"，集思广益探讨系统可能如何被破坏或受到损害。每个识别的威胁都会被列出，以便项目可以考虑如何主动避免或关闭可能出现的任何漏洞/脆弱点。确保为新功能或破坏性更改更新此分析。

    docs/threat-model.md contains the attack-surface analysis: a trust-boundary diagram identifying the four boundaries that carry untrusted data (the browser, the MCP client, and the two outbound integrations whose responses the application parses), thirteen numbered threats with controls and residual risk, and named critical code paths including LoginFormAuthenticator, LdapClientService, ScopeGuard and the raw DBAL call sites in EntryRepository. See https://github.com/netresearch/timetracker/blob/main/docs/threat-model.md


    不足以获得徽章。

    软件组件中不影响本项目的任何漏洞必须在VEX文档中予以记录，通过补充不可利用性的详细信息来完善漏洞报告。 [OSPS-VM-04.02]
    建立VEX供给源，传达已知漏洞的可利用性状态，包括评估细节或任何阻止易受攻击代码执行的缓解措施。

    The project does not publish VEX documents. Dependency findings that do not affect the application are currently handled ad hoc rather than recorded with non-exploitability statements.


    足够获得徽章！

    项目文档必须包含一项政策，为与漏洞和许可证相关的软件成分分析（SCA）发现结果的修复设定阈值。 [OSPS-VM-05.01]
    在项目中记录一项政策，定义与漏洞和许可证相关的SCA发现的修复阈值。包括识别、优先级排序和修复这些发现的流程。

    docs/vulnerability-management.md defines the thresholds and the remediation timelines: composer audit blocks on any advisory at any severity, bun audit and npm audit block at high and above, and fixes are due within 7 days for Critical, 30 days for High, the next minor release for Medium and the next scheduled dependency run for Low. Licence and selection criteria are in docs/dependency-policy.md. See https://github.com/netresearch/timetracker/blob/main/docs/vulnerability-management.md


    不足以获得徽章。

    项目文档必须包含一项政策，要求在任何发布之前处理软件成分分析（SCA）违规问题。 [OSPS-VM-05.02]
    在项目中记录一项政策，在任何发布之前解决适用的软件组成分析结果，并添加状态检查以验证在发布之前符合该政策。

    The project has no documented policy requiring SCA violations to be resolved before a release. Releases are created manually and are not gated on dependency-audit results.


    足够获得徽章！

    对项目代码库的所有更改都必须根据针对恶意依赖项和依赖项中已知漏洞的书面政策进行自动评估，并在出现违规情况时予以阻止，但已声明并抑制为不可利用的情况除外。 [OSPS-VM-05.03]
    在项目的版本控制系统中创建一个状态检查，对代码库的所有更改运行软件组成分析工具。要求状态检查在更改可以合并之前必须通过。

    Every pull request and push is evaluated against the documented policy in docs/vulnerability-management.md, and violations block the merge: composer audit (any severity) runs in the CI lint job and bun audit --audit-level=high runs in the frontend job, both without continue-on-error, and both jobs are inputs to the 'CI Success' aggregate, which is a required status check on main. npm audit additionally runs via security.yml. See https://github.com/netresearch/timetracker/blob/main/.github/workflows/ci.yml


    不足以获得徽章。

    项目文档必须包含一项政策，为静态应用程序安全测试（SAST）发现结果的修复设定阈值。 [OSPS-VM-06.01]
    在项目中记录一项政策，定义静态应用程序安全测试（SAST）发现的修复阈值。包括识别、优先级排序和修复这些发现的流程。

    No documented remediation-threshold policy for SAST findings exists in the project documentation. Thresholds are configured in GitHub code scanning protection rules (high or higher for security alerts), and PHPStan runs at level 10 with an empty baseline, but neither is written down as project policy.


    不足以获得徽章。

    对项目代码库的所有更改都必须根据书面政策针对安全弱点进行自动评估，并在出现违规情况时予以阻止，但已声明并抑制为不可利用的情况除外。 [OSPS-VM-06.02]
    在项目的版本控制系统中创建一个状态检查，对代码库的所有更改运行静态应用程序安全测试（SAST）工具。要求状态检查在更改可以合并之前必须通过。

    Evaluation is now broad but only partly blocking. PHPStan at level 10 with an empty baseline, PHPat, Rector and PHP-CS-Fixer run in the CI lint job and do block, since 'CI Success' is a required status check. CodeQL covers javascript-typescript and the new semgrep.yml covers PHP with p/php, p/security-audit and p/secrets, uploading SARIF to code scanning — but semgrep is deliberately non-blocking ('the job does not fail the build') and is not part of the required checks, and code scanning findings are triaged rather than gated. With no documented severity threshold for SAST findings either, this is not yet met.



您可以使用工具和AI系统通过简单的URL提交变更建议，例如 https://www.bestpractices.dev/zh-CN/projects/11719/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced。请参阅我们的自动化提案系统，了解具体操作方法。 该数据可在社区数据许可协议 – 许可性，版本 2.0 (CDLA-Permissive-2.0)下获取。这意味着数据接收方可以共享数据，无论是否经过修改，只要数据接收方在共享数据时提供本协议文本。请注明Sebastian Mendel和OpenSSF最佳实践徽章贡献者。

项目徽章条目拥有者： Sebastian Mendel.
最后更新于 2026-01-09 06:05:12 UTC, 最后更新于 2026-09-20 17:21:08 UTC。 最后在 2026-02-25 23:03:38 UTC 获得通过徽章。