Security at GitLab  GitLab 的安全性

Security Vision and Mission
安全願景與使命

Our vision is to transparently lead the world to secure outcomes.
我們的願景是透明地引領世界達成安全成果。

Our mission is to enable everyone to innovate and succeed on a safe, secure, and trusted DevSecOps platform. This will be achieved through 5 security operating principles:
我們的使命是讓每個人在一個安全、可靠的 DevSecOps 平台上創新和成功。這將通過五個安全運營原則來實現：

  1. Accelerate business success with a focus on:
    專注於加速業務成功：
    • Prioritize ‘boring’, iterative solutions that minimize risk
      優先考慮「無趣」、迭代的解決方案，以將風險降至最低。
    • Find ways to say Yes
      尋找說「是」的方法
    • Understand goals before recommending solutions
      在建議解決方案之前了解目標
    • Use GitLab first  優先使用 GitLab
  2. Efficient operations with a focus on:
    專注於高效運營：
    • Technical controls over handbook rules
      手冊規則的技術控制
    • Leverage automation first (robots over humans)
      優先利用自動化（機器人優於人力）
    • Responsible decisions (Spending, Tooling, Staffing, etc) over low ROI (return on investment) decisions
      負責任的決策（支出、工具、員工配置等）優於低投資回報率的決策
    • Reusable or repeatable over singular solutions
      可重複使用或可重複的方案優於單一解決方案
  3. Transparency with a focus on:
    專注於透明性：
    • Responsible protection of MNPI (material non-public information)
      負責任地保護 MNPI（重大非公開資訊）
    • Evangelize dogfooding of GitLab publicly
      公開推廣 GitLab 的內部測試
    • Lead with metrics  以指標為導向
    • Balance security with usefulness
      在安全性與實用性之間取得平衡
  4. Risk Reduction with a focus on:
    專注於風險降低
    • Secure by default  預設安全
    • Preventative controls over detective controls
      預防性控制優於偵測性控制
    • Solving root causes over treating symptoms
      解決根本原因而非治標
    • Visibility through Coverage, Discoverability, Observability
      透過覆蓋率、可發現性、可觀察性來提高可見性
  5. Collaborative Culture with a focus on:
    專注於協作文化：
    • Working together on common solutions
      共同合作尋找通用解決方案
    • Solve shared problems with shared solutions
      以共享的解決方案解決共同的問題
    • Simplifying language for everyone to understand
      簡化語言以便每個人都能理解
    • Avoiding security jargon
      避免使用安全術語
    • Seek opportunities to help others succeed
      尋找機會幫助他人成功

To help achieve the vision of transparently leading the world to secure outcomes, the Security Division has nominated a Security Culture Committee.
為了實現透明地引領世界達成安全成果的願景，安全部門已提名了一個安全文化委員會。

Division Structure  部門結構

The Security Division provides essential security operational services, is directly engaged in the development and release processes, and offers consultative and advisory services to better enable the business to function while minimising risk.
安全部門提供基本的安全運營服務，直接參與開發和發布流程，並提供諮詢和建議服務，以更好地支持業務運作，同時將風險降至最低。

To reflect this, we have structured the Security Division around four key tenets, which drive the structure and the activities of our group. These are :
為了反映這一點，我們圍繞四個關鍵原則構建了安全部門，這些原則驅動著我們團隊的結構和活動。這些原則是：

Product Security  產品安全
Security Operations  安全運營
Corporate Security  企業安全
Security Assurance  安全保證

Secure the Product - The Product Security Department
產品安全 - 產品安全部門

The Product Security Department is primarily focused on Securing the Product. This reflects the Security Division’s current efforts to be involved in the Application development and Release cycle for Security Releases, Infrastructure Security, and our HackerOne bug bounty program.
產品安全部門主要專注於產品的安全性。這反映了安全部門目前在應用程式開發和發布週期中參與安全發布、基礎設施安全以及我們的 HackerOne 漏洞賞金計畫的努力。

The term “Product” is interpreted broadly and includes the GitLab application itself and all other integrations and code that is developed internally to support the GitLab application for the multi-tenant SaaS. Our responsibility is to ensure all aspects of GitLab that are exposed to customers or that host customer data are held to the highest security standards, and to be proactive and responsive to ensure world-class security in anything GitLab offers.
「產品」一詞被廣泛解釋，包括 GitLab 應用程式本身以及所有其他內部開發的整合和代碼，以支持多租戶 SaaS 的 GitLab 應用程式。我們的責任是確保所有面向客戶或承載客戶數據的 GitLab 方面都符合最高的安全標準，並積極主動地確保 GitLab 提供的任何服務都具備世界級的安全性。

Protect the Company - The Security Operations Department
保護公司 - 安全運營部門

Security Operations Department teams are primarily focused on protecting GitLab the business and GitLab’s platform. This encompasses protecting company property as well as to prevent, detect and respond to risks and events targeting the business and our platform. This department includes the Security Incident Response Team (SIRT) and the Trust and Safety team.
安全運營部門的團隊主要專注於保護 GitLab 的業務和 GitLab 的平台。這包括保護公司財產以及預防、檢測和應對針對業務和我們平台的風險和事件。該部門包括安全事件響應團隊（SIRT）和信任與安全團隊。

These functions have the responsibility of shoring up and maintaining the security posture of GitLab’s platform to ensure enterprise-level security is in place to protect our new and existing customers.
這些職能負責加強和維護 GitLab 平台的安全態勢，以確保具備企業級的安全性來保護我們的新客戶和現有客戶。

Lead with Data - The Threat Management Department
以數據為主導 - 威脅管理部門

Threat Management Department teams are cross-functional. They are responsible for collaborating across the Security Division to identify, communicate, and remediate threats or vulnerabilities that may impact GitLab, our Team Members or our users and the community at large.
威脅管理部門的團隊是跨職能的。他們負責在安全部門內協作，以識別、溝通和修復可能影響 GitLab、我們的團隊成員或我們的用戶及整個社群的威脅或漏洞。

Assure the Customer - The Security Assurance Department
保障客戶 - 安全保證部門

The Security Assurance Department is comprised of the teams noted above. They target Customer Assurance projects among their responsibilities. This reflects the need for us to provide resources to our customers to assure them of the security and safety of GitLab as an application to use within their organisation and as a enterprise-level SaaS. This also involves providing appropriate support, services and resources to customers so that they trust GitLab as a Secure Company, as a Secure Product, and Secure SaaS
安全保證部門由上述團隊組成。他們的職責之一是針對客戶保證專案。這反映了我們需要向客戶提供資源，以確保他們在其組織內使用 GitLab 作為應用程式以及作為企業級 SaaS 的安全性和可靠性。這也涉及向客戶提供適當的支持、服務和資源，以便他們信任 GitLab 作為一個安全的公司、安全的產品和安全的 SaaS。

Protect the Organization - Corporate Security
保護組織 - 企業安全

GitLab is both a company and a product. The Corporate Security department focuses on implementing and protecting the information technology (IT) related systems that the company uses to conduct business internally, and provides the hardware, software, and tools that our team members and 3rd party service providers (aka contractors) need to be productive and get their job done efficiently. The configurations that we implement for team members internally are designed to protect our customers and their data.
GitLab 既是一家公司也是一款產品。企業安全部門專注於實施和保護公司用於內部業務的資訊技術（IT）相關系統，並提供我們的團隊成員和第三方服務提供商（即承包商）所需的硬體、軟體和工具，以提高生產力並有效完成工作。我們為內部團隊成員實施的配置旨在保護我們的客戶及其數據。

We have a 24x5 technical support helpdesk for team members and have engineers that configure and maintain many of our company-wide tech stack applications.
我們為團隊成員提供 24x5 的技術支援服務台，並有工程師負責配置和維護我們公司範圍內的多個技術堆疊應用程式。

We invest heavily in device trust, identity management, and infrastructure governance to provide the highest level of security assurance for the administrators of our product and ensure all appropriate controls are in place when handling customer data.
我們在設備信任、身份管理和基礎設施治理方面投入大量資源，以為我們產品的管理員提供最高級別的安全保證，並確保在處理客戶數據時所有適當的控制措施都已到位。

Other groups and individuals
其他團體和個人

Security Program Management
安全計劃管理

Security Program Management is responsible for complete overview and driving security initiatives across Product, Engineering, and Business Enablement. This includes the tracking, monitoring, and influencing priority of significant security objectives, goals, and plans/roadmaps from all security sub-departments. Security Program Manager Job Family
安全計劃管理負責全面概覽並推動產品、工程和業務啟用的安全計劃。這包括跟蹤、監控和影響所有安全子部門的重要安全目標、計劃和路線圖的優先級。安全計劃經理職位系列

Security Program areas of focus
安全計劃的重點領域
  • Drive Accountability & Visibility for Program Objectives & Goals
    推動計劃目標和目標的問責制和可見性
  • Drive, Gather, & Examine Program Needs & Opportunities through Intra & Inter Organizational Collaboration
    通過內部和跨組織合作推動、收集和檢查計劃需求和機會
  • Provide Insights & Suggestions Impacting Program Strategy & Roadmap
    提供影響計劃策略與路線圖的見解與建議
  • Assist in Gathering & Prioritizing Program Risks, Requirements, & Alignment to Influence Remediation
    協助收集與優先排序計劃風險、需求及對齊，以影響補救措施
  • Drive & Define Acceptance Criteria, Value Proposition, Milestones to Visualize and Communicate Program Effectiveness
    推動並定義驗收標準、價值主張、里程碑，以視覺化和傳達計劃的有效性
  • Develop Repeatable, Scalable, Efficient, Effective, Processes & Procedures
    開發可重複、可擴展、高效且有效的流程與程序

Product development  產品開發

In keeping with our core values and the belief that everyone can contribute, the Security Division is committed to dogfooding and contributing to the development of the GitLab product.
秉持著我們的核心價值觀以及每個人都能貢獻的信念，安全部門致力於內部測試並貢獻於 GitLab 產品的開發。

Contacting the Team
聯繫團隊

Reporting vulnerabilities and security issues
報告漏洞和安全問題

For information regarding GitLab’s HackerOne bug bounty program, and creating and scheduling security issues, please see our engaging with security page and our Responsible Disclosure Policy.
有關 GitLab 的 HackerOne 漏洞賞金計劃，以及創建和安排安全問題的資訊，請參閱我們的安全互動頁面和負責任的披露政策。

Reporting an Incident  報告事件

If an urgent security incident has been identified or you suspect an incident may have occurred, please refer to Engaging the Security Engineer On-Call. Examples include, but are not limited to:
如果發現緊急安全事件或懷疑可能發生事件，請參考聯繫值班安全工程師。範例包括但不限於：

  • Lost or stolen devices
    遺失或被竊的設備
  • Leaked credentials  洩露的憑證
  • Endpoint compromise or infection
    端點妥協或感染
  • Exposure of sensitive GitLab data
    敏感 GitLab 資料的暴露

GitLab provides a panic@gitlab.com email address for team members to use in situations when Slack is inaccessible and immediate security response is required.
GitLab 提供了一個 panic@gitlab.com 電子郵件地址，供團隊成員在無法使用 Slack 且需要立即安全回應的情況下使用。

This email address is only accessible to GitLab team members and can be reached from their gitlab.com or personal email address as listed in Workday. Using this address provides an excellent way to limit the damage caused by a loss of one of these devices.
此電子郵件地址僅限於 GitLab 團隊成員使用，並且可以從他們在 Workday 中列出的 gitlab.com 或個人電子郵件地址聯繫。使用此地址提供了一種限制因這些設備之一丟失而造成損害的絕佳方式。

Additionally if a GitLab team member experiences a personal emergency the People Group also provides an emergency contact email.
此外，如果 GitLab 團隊成員遇到個人緊急情況，People Group 也提供了一個緊急聯絡電子郵件。

Sub-groups and projects  子群組和專案

Many teams follow a convention of having a GitLab group team-name-team with a primary project used for issue tracking underneath team-name or similar.
許多團隊遵循一種慣例，即擁有一個 GitLab 群組 team-name-team ，並在其下設有一個主要專案用於問題追蹤，位於 team-name 或類似位置。

Slack Channels  Slack 頻道

  • #security_help: The catch-all channel for security questions that are not direct support requests. If you’re not sure where to go, start here.
    #security_help：用於所有非直接支援請求的安全問題。如果您不確定該去哪裡，請從這裡開始。
  • #it_help: For all your internal end user support needs and CorpSec support needs. All support related questions and requests should be directed here.
    #it_help：滿足您所有內部終端使用者支援需求和 CorpSec 支援需求。所有與支援相關的問題和請求應該在此處提出。
  • #security_discuss: Security discussions, announcements, and regular updates from the security teams. This is a good channel for cross-function collaboration with internal transparency.
    #security_discuss：安全討論、公告和安全團隊的定期更新。這是一個適合跨功能協作並保持內部透明的良好頻道。
  • #abuse: Used for reporting suspected abusive activity/content (GitLab Internal) as well as general discussions regarding anti-abuse efforts. Use @trust-and-safety in the channel to alert the team to anything urgent.
    #abuse：用於報告可疑的濫用活動/內容（GitLab 內部）以及有關反濫用工作的常規討論。在頻道中使用 @trust-and-safety 來提醒團隊任何緊急事項。
  • #ciso: For general communication from our CISO and CISO Directs. Team and division updates and other topics.
    #ciso：用於我們的首席資訊安全官（CISO）及其直屬部門的一般溝通。團隊和部門更新及其他主題。

The following group tags can help you get the attention of a specific department, team, or specialty:
以下群組標籤可以幫助您獲得特定部門、團隊或專業的注意：

Primary Security departments:
主要安全部門：

  • @security-assurance: Contains all members of the Security Assurance department.
    @security-assurance：包含所有安全保證部門的成員。
  • @security-corpsec: Contains all members of the Corporate Security department.
    @security-corpsec：包含所有企業安全部門的成員。
  • @security-prodsec: Contains all members for the Product Security department.
    @security-prodsec：包含所有產品安全部門的成員。
  • @security-operations: Contains all members of the Security Operations department. If you need to open a security incident, please use the Slack slash command /security instead of a tag.
    @security-operations：包含所有安全運營部門的成員。如果您需要開啟安全事件，請使用 Slack 斜線命令 /security 而不是標籤。

Leadership and program support:
領導和計畫支持：

  • @security-leadership: All Security people-managers
    @security-leadership：所有安全人員管理者
  • @security-program-mgmt: All security program management team members
    @security-program-mgmt：所有安全計畫管理團隊成員

Specific teams and specialties:
特定團隊和專業：

  • @fedramp-compliance: All SecAssurance members that support FedRAMP
    @fedramp-compliance: 所有支持 FedRAMP 的 SecAssurance 成員
  • @security-governance: All members of the Security Governance team
    @security-governance：安全治理團隊的所有成員
  • @sirt-members: All members of the Security Incident Response Team (SIRT)
    @sirt-members：安全事件響應團隊（SIRT）的所有成員
  • @sec-assurance-team: All members of the Security Compliance, Risk, and Governance & Field Security teams
    @sec-assurance-team：安全合規、風險與治理及現場安全團隊的所有成員
  • @field-security: All members of the Field Security team
    @field-security：現場安全團隊的所有成員
  • @appsec-team: All members of the Application Security team
    @appsec-team: 應用程式安全團隊的所有成員
  • @trust-and-safety: All members of the Trust & Safety team
    @trust-and-safety: 信任與安全團隊的所有成員
  • @security-identity: All members of the Identity team
    @security-identity: 身份團隊的所有成員
  • @red-team: All members of GitLab’s Red Team
    @red-team: GitLab 紅隊的所有成員
  • @threat-intelligence: All members of GitLab’s Threat Intelligence team
    @threat-intelligence：GitLab 威脅情報團隊的所有成員

Division, Department, and Team updates
部門、部門和團隊更新

We believe it is important to share regular updates at various levels of the Security Division, and we use Slack as the primary mechanism for providing these updates. Our updates are open to all GitLab team members using the following process:
我們認為在安全部門的各個層級定期分享更新是很重要的，我們使用 Slack 作為提供這些更新的主要機制。我們的更新對所有 GitLab 團隊成員開放，使用以下流程：

  • Start of each month: A thread per-department is started in #security_discuss by each department leader (CorpSec, ProdSec, SecAssurance, SecOps). These threads are pinned for the duration of the month.
    每月開始：每個部門的領導（CorpSec、ProdSec、SecAssurance、SecOps）在 #security_discuss 中開始一個每個部門的線程。這些線程會在整個月內被置頂。
    • Thread template:   線程模板：
      • <MONTH> <DEPARMENT> Weekly Updates
      • Example: August Product Security Weekly Updates  範例： August Product Security Weekly Updates
  • Weekly: At least once a week, teams provide updates they wish to share within the appropriate thread. For example, updates from Vulnerability Management would be placed in the Product Security thread for the given month.
    每週：每週至少一次，各團隊在適當的討論串中提供他們希望分享的更新。例如，漏洞管理的更新將放在當月的產品安全討論串中。
    • These weekly updates, while highly encouraged, are strictly optional and should represent content that ICs and managers feel should be highlighted. Teams are encouraged to define processes and DRIs around these updates that work for them.
      這些每週更新雖然非常鼓勵，但完全是可選的，應該代表個人貢獻者和經理認為應該突出的內容。鼓勵各團隊定義適合他們的更新流程和直接負責人。
    • Individuals providing the weekly updates are encouraged to use the “Also send to #security_discuss” option within the thread to increase visibility.
      提供每週更新的個人被鼓勵在討論串中使用「也發送到 #security_discuss」選項以增加可見度。
  • End of each month: Departmental leaders prepare a monthly update, including no more than three updates per team, and post it in #ciso within the first week of the following month.
    每月底：部門領導準備每月更新，每個團隊不超過三個更新，並在次月的第一週內將其發布在 #ciso 。
    • Each monthly update should include a brief preface written by the departmental leader covering any notable themes or other strategic updates.
      每月更新應包括由部門領導撰寫的簡短前言，涵蓋任何值得注意的主題或其他策略性更新。
    • Each of the three updates per-team should be no more than 2-3 sentences and include at least one link to allow readers to gain additional context. Links should be to GitLab Issues or Epics wherever possible. If information is confidential and not able to be added to an Issue or Epic, a note should be added indicating this.
      每個團隊的三個更新應不超過 2-3 句，並至少包含一個鏈接，以便讀者獲得更多背景資訊。鏈接應盡可能指向 GitLab Issues 或 Epics。如果資訊是機密且無法添加到 Issue 或 Epic，應添加註釋說明。
    • It is recommended that departmental leaders build their monthly update over the course of the month via a GitLab issue (see an example) in collaboration with their managers and senior ICs.
      建議部門領導在整個月內透過 GitLab 問題（參見範例）與其經理和高級個人貢獻者合作，建立他們的每月更新。

Twice-Monthly Security Leadership Meetings
每月兩次的安全領導會議

Security Leadership meets twice a month over Zoom to discuss division-wide topics. Individual contributors from across the security organization are invited to present their work, ideas, or projects to this leadership forum.
安全領導團隊每月兩次通過 Zoom 會議討論整個部門的議題。來自安全組織的個別貢獻者被邀請在這個領導論壇上展示他們的工作、想法或專案。

If you’re interested in presenting:
如果您有興趣進行展示：

  1. Discuss the topic with your manager first
    首先與您的經理討論該主題
  2. Your manager will help you:
    您的經理將協助您：
    • Add your topic to the agenda with supporting materials
      將您的主題添加到議程中，並附上支持材料
    • Request an appropriate time slot (5-25 minutes)
      請求一個合適的時間段（5-25 分鐘）
    • Coordinate scheduling your presentation
      協調安排您的演示時間

Note that these meetings are not on the general Security calendar. Your manager will ensure you receive the meeting invitation for your scheduled time.
請注意，這些會議不在一般的安全日曆上。您的經理將確保您在預定時間收到會議邀請。

We encourage all team members to take advantage of this opportunity to share your work and insights with security leadership.
我們鼓勵所有團隊成員利用這個機會，與安全領導層分享你的工作和見解。

Ransomware  勒索軟體

For an overview of the communication and response process for a suspected ransomware attack, please see our Responding to Ransomware page.
如需了解疑似勒索軟體攻擊的溝通和應對流程，請參閱我們的應對勒索軟體頁面。

Important topics  重要主題

Tokens  令牌

The following best practices will help ensure tokens are handled appropriately at GitLab. For detailed requirements regarding the use of tokens at GitLab, please see our token management standard.
以下最佳實踐將有助於確保在 GitLab 中妥善處理令牌。有關在 GitLab 使用令牌的詳細要求，請參閱我們的令牌管理標準。

  1. When creating a Personal Access Token, be sure to choose the appropriate scopes that only have the permissions that are absolutely necessary.
    在創建個人訪問令牌時，務必選擇僅具有絕對必要權限的適當範圍。
  2. Oftentimes a Project Access Token might be sufficient instead of a Personal Access Token. Project Access Tokens have a much more limited scope and should be preferred over Personal Access Tokens whenever possible.
    通常情況下，專案訪問令牌可能就足夠了，而不需要使用個人訪問令牌。專案訪問令牌的範圍更為有限，應在可能的情況下優先選擇專案訪問令牌。
  3. Always set an expiration for your tokens when creating them. Tokens should preferably expire in a matter of hours or a day.
    創建令牌時，務必設置令牌的到期時間。令牌最好在幾小時或一天內過期。
  4. Be mindful to keep these personal access tokens secret. Be particularly careful not to accidentally commit them in configuration files, paste them into issue or merge request comments, or otherwise expose them.
    務必謹慎保密這些個人訪問令牌。特別小心不要不小心將它們提交到配置文件中，或粘貼到問題或合併請求的評論中，或以其他方式暴露它們。
  5. Please consider periodically reviewing your currently active Personal Access Tokens and revoking any that are no longer needed.
    請考慮定期檢查您當前使用中的個人訪問權杖，並撤銷任何不再需要的權杖。
  6. Personal Access Tokens will be highly discouraged within the GitLab production environment, and disallowed/disabled wherever possible. Existing tokens shall remain, but additional issuance will not be permissible/possible.
    在 GitLab 生產環境中將極力不建議使用個人訪問權杖，並在可能的情況下禁止/停用。現有的權杖將保留，但不允許/無法再發行新的權杖。
  7. If you believe a personal access token has been leaked, revoke it immediately (if possible) and contact the security team using the /security Slack command.
    如果您認為個人訪問令牌已洩露，請立即撤銷（如果可能）並使用 /security Slack 指令聯繫安全團隊。

Receive notification of security releases
接收安全版本發布通知

  • To receive security release blog notifications delivered to your inbox, visit our contact us page.
    若要接收安全版本發布的部落格通知至您的收件箱，請造訪我們的聯絡我們頁面。
  • To receive release notifications via RSS, subscribe to our security release RSS feed or our RSS feed for all releases.
    若要通過 RSS 接收版本發布通知，請訂閱我們的安全版本發布 RSS 訂閱源或所有版本的 RSS 訂閱源。
  • For additional information regarding security releases, please visit the Delivery Team’s security releases page.
    如需有關安全版本的更多資訊，請造訪交付團隊的安全版本頁面。

Resources  資源

Tools  工具

  • Incident-Tools (private) for working scripts and other code during or while remediating an incident. If the tool is applicable outside of the GitLab.com environment, consider if it’s possible to release when the ~security issue becomes non-confidential. This group can also be used for private demonstration projects for security issues.
    Incident-Tools（私人）用於在處理或修復事件期間的工作腳本和其他代碼。如果該工具適用於 GitLab.com 環境之外，請考慮在 ~security 問題不再保密時發布。此群組也可用於安全問題的私人示範專案。
  • security-tools (mostly private) contains some operational tools used by the security teams. Contents and/or configurations require that most of these projects remain private.
    security-tools（大多為私人）包含一些由安全團隊使用的操作工具。內容和/或配置要求這些專案大多保持私密。

Calendar  日曆

We welcome GitLab team members to join meetings that are on our shared Security Calendar.
我們歡迎 GitLab 團隊成員參加我們共享的安全日曆上的會議。

Other Frequently Used GitLab.com Projects
其他常用的 GitLab.com 專案

Security crosses many teams in the company, so you will find ~security labeled issues across all GitLab projects, especially:
安全涉及公司內的多個團隊，因此你會在所有 GitLab 專案中找到標記為 ~security 的問題，特別是：

When opening issues, please follow the Creating New Security Issues process for using labels and the confidential flag.
在開啟問題時，請遵循創建新安全問題的流程來使用標籤和機密標誌。

Other Resources for GitLab Team Members
GitLab 團隊成員的其他資源

Last modified July 23, 2025: Update to new security slack channels (0c235bd1)
最後修改於 2025 年 7 月 23 日：更新至新的安全 Slack 頻道（ 0c235bd1 ）
View page source - Edit this page - please contribute. Creative Commons License
查看頁面來源 - 編輯此頁面 - 請貢獻。（ Creative Commons License ）