security-compliance by davila7/claude-code-templates
npx skills add https://github.com/davila7/claude-code-templates --skill security-compliance应用多层安全控制,这样即使一层失效,其他层也能提供保护。切勿依赖单一的安全机制。
从不信任,始终验证。假设存在漏洞,无论位置或网络如何,都要验证每一个访问请求。
授予用户和系统执行其功能所需的最小访问权限。定期审查并撤销未使用的权限。
从系统设计的最早阶段就整合安全要求,而不是事后补救。
实施持续的监控和告警,以实时检测异常和安全事件。
基于风险评估确定安全工作的优先级,将资源集中在最关键资产和最可能的威胁上。
使用合规框架作为基线,但要超越最低要求以实现真正的安全。
通过规划、测试和定期的桌面演练为安全事件做好准备。假设一定会发生入侵。
目标:了解当前安全状况和合规要求
活动:
交付成果:
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
目标:设计安全的系统和架构
活动:
交付成果:
目标:部署安全控制措施并加固系统
活动:
交付成果:
目标:持续监控威胁和异常
活动:
交付成果:
目标:响应安全事件并恢复运营
活动:
交付成果:
目标:验证合规性并持续改进安全
活动:
交付成果:
使用时机:评估安全风险并确定缓解工作的优先级
流程:
1. 识别资产
- 需要保护哪些系统、数据和服务?
- 每个资产的业务价值是什么?
- 资产所有者是谁?
2. 识别威胁
- 哪些威胁行为者可能针对这些资产? (国家、网络犯罪分子、内部人员)
- 他们的动机是什么? (经济利益、间谍活动、破坏)
- 当前的威胁趋势是什么?
3. 识别漏洞
- 系统或流程中存在哪些弱点?
- 缺少哪些安全控制措施或哪些控制措施无效?
- 影响您系统的已知 CVE 有哪些?
4. 计算风险
风险 = 可能性 × 影响
可能性等级 (1-5):
1 = 罕见 (1 年内发生几率 < 5%)
2 = 不太可能 (5-25%)
3 = 可能 (25-50%)
4 = 很可能 (50-75%)
5 = 几乎肯定 (> 75%)
影响等级 (1-5):
1 = 最小 (< 1 万美元损失,无数据泄露)
2 = 轻微 (1-10 万美元,有限的数据暴露)
3 = 中等 (10-100 万美元,重大数据泄露)
4 = 重大 (100-1000 万美元,广泛的数据泄露,监管罚款)
5 = 灾难性 (> 1000 万美元,威胁业务生存)
风险评分 = 可能性 × 影响 (最高 25)
5. 确定风险优先级
- 关键: 风险评分 15-25 (立即行动)
- 高: 风险评分 10-14 (30 天内行动)
- 中: 风险评分 5-9 (90 天内行动)
- 低: 风险评分 1-4 (监控并接受)
6. 确定风险应对措施
- 缓解: 实施控制措施以降低风险
- 接受: 如果风险在容忍范围内,则记录接受
- 转移: 使用保险或第三方服务
- 规避: 消除产生风险的活动
输出:包含优先风险和缓解计划的风险登记册
使用时机:为已识别的风险选择适当的安全控制措施
框架:使用 NIST CSF 类别或 CIS 控制措施
NIST CSF 功能:
1. 识别 (ID)
- 资产管理
- 风险评估
- 治理
2. 保护 (PR)
- 访问控制
- 数据安全
- 保护技术
3. 检测 (DE)
- 异常和事件
- 安全监控
- 检测流程
4. 响应 (RS)
- 响应规划
- 沟通
- 分析和缓解
5. 恢复 (RC)
- 恢复规划
- 改进
- 沟通
控制措施类型:
- 预防性: 在事件发生前阻止 (MFA, 防火墙, 加密)
- 检测性: 事件发生时识别 (SIEM, IDS, 日志监控)
- 纠正性: 检测后修复问题 (打补丁, 事件响应)
- 威慑性: 阻止攻击者 (安全策略, 警告)
- 补偿性: 当主要控制措施不可行时的替代控制措施
选择标准:
1. 它是否解决了已识别的风险?
2. 是否具有成本效益? (控制成本 < 风险价值)
3. 技术上是否可行?
4. 是否满足合规要求?
5. 我们能否维护和监控它?
使用时机:确定要实施哪些合规框架
决策树:
您是什么类型的组织?
├─ SaaS/云服务提供商
│ ├─ 向企业销售? → SOC2 Type II (必需)
│ ├─ 有国际客户? → ISO27001 (强烈推荐)
│ ├─ 处理健康数据? → HIPAA + HITRUST
│ └─ 处理支付卡? → PCI-DSS
├─ 医疗保健提供商/支付方
│ ├─ 总部在美国 → HIPAA (必需)
│ ├─ 国际 → HIPAA + GDPR
│ └─ 附加: HITRUST 作为综合框架
├─ 金融服务
│ ├─ 美国银行 → GLBA, SOX (如果是上市公司)
│ ├─ 支付处理 → PCI-DSS (必需)
│ ├─ 国际 → ISO27001, 当地法规
│ └─ 附加: NIST CSF 作为框架
├─ 电子商务/零售
│ ├─ 接受信用卡 → PCI-DSS (必需)
│ ├─ 欧盟客户 → GDPR (必需)
│ ├─ 加利福尼亚州客户 → CCPA
│ └─ B2B 销售 → SOC2 Type II
└─ 一般企业
├─ 向企业销售 → SOC2 Type II
├─ 希望获得广泛认可 → ISO27001
├─ 政府合同 → FedRAMP, NIST 800-53
└─ 行业特定 → 检查行业法规
多框架策略:
- 从以下开始: SOC2 或 ISO27001 (选择一个作为基础)
- 添加: 数据隐私法规 (GDPR, CCPA) 根据需要
- 叠加: 行业特定要求
使用时机:对安全事件进行分类和响应
严重性等级:
P0 - 关键 (立即响应)
- 正在发生数据外泄的主动入侵
- 正在进行的勒索软件加密
- 关键服务的完全系统中断
- 对生产数据库的未经授权访问
- 响应: 立即召集 CIRT,通知高管,24/7 工作
P1 - 高 (1 小时内响应)
- 关键系统上确认存在恶意软件
- 尝试未经授权访问敏感数据
- 影响可用性的 DDoS 攻击
- 存在活跃漏洞利用的重大漏洞
- 响应: 召集 CIRT,通知经理,工作到事件被控制
P2 - 中 (4 小时内响应)
- 非关键系统上的恶意软件
- 可疑账户活动
- 具有安全影响的策略违规
- 需要打补丁的漏洞
- 响应: 安全团队调查,工作时间
P3 - 低 (24 小时内响应)
- 失败的登录尝试 (低于阈值)
- 轻微的策略违规
- 信息性安全事件
- 响应: 标准队列,记录发现结果
分类因素:
1. 数据机密性影响 (PHI, PII, 财务数据, 知识产权)
2. 系统可用性影响 (收入, 运营)
3. 数据完整性影响 (损坏, 未经授权的更改)
4. 受影响的系统/用户数量
5. 监管报告要求
使用时机:确定漏洞修复的优先级
框架:结合业务背景的增强型 CVSS
基础 CVSS 评分 × 业务背景乘数 = 优先级评分
CVSS 严重性范围:
- 关键: 9.0-10.0
- 高: 7.0-8.9
- 中: 4.0-6.9
- 低: 0.1-3.9
业务背景乘数:
- 面向互联网的生产系统: 2.0×
- 内部生产系统: 1.5×
- 包含敏感数据的系统: 1.5×
- 开发/测试环境: 0.5×
- 野外存在活跃漏洞利用: 2.0×
- 已部署补偿性控制措施: 0.7×
优先级等级:
- P0 (关键): 评分 ≥ 14 → 24-48 小时内打补丁
- P1 (高): 评分 10-13.9 → 7 天内打补丁
- P2 (中): 评分 6-9.9 → 30 天内打补丁
- P3 (低): 评分 < 6 → 90 天内打补丁或接受风险
其他考虑因素:
- 系统能否被隔离/分段?
- 是否有有效的检测性控制措施?
- 打补丁的复杂性/风险如何?
- 是否有供应商补丁可用?
使用时机:评估供应商和合作伙伴的安全风险
评估框架:
1. 对供应商风险等级进行分类
低风险 (最小化评估):
- 无系统或数据访问权限
- 集成有限
- 非关键服务
→ 简单问卷
中风险 (标准评估):
- 有限的系统访问权限
- 非敏感数据访问权限
- 重要但非关键的服务
→ 安全问卷 + 证据审查
高风险 (全面评估):
- 生产系统访问权限
- 敏感数据处理
- 关键服务依赖
→ 全面评估 + 审计报告 + 渗透测试
关键风险 (广泛评估):
- 完全的生产访问权限
- PHI/PII 处理
- 业务关键依赖
→ 现场审计 + 持续监控 + SLA
2. 评估组成部分
针对中/高/关键供应商:
□ 安全问卷 (SIG, CAIQ 或自定义)
□ 合规认证 (SOC2, ISO27001)
□ 保险证书 (网络责任险)
□ 安全策略和程序
□ 事件响应计划
□ 灾难恢复/业务连续性计划
□ 数据处理协议 (DPA)
□ 渗透测试结果 (针对高/关键供应商)
□ 合同中的审计权条款
3. 持续监控
- 年度重新评估
- 监控违规/事件
- 审查安全更新和补丁
- 跟踪合规认证续期
- 进行定期审计 (针对关键供应商)
4. 供应商风险评分
计算评分 (0-100):
- 安全成熟度: 40 分
- 合规认证: 20 分
- 事件历史: 15 分
- 财务稳定性: 15 分
- 参考和声誉: 10 分
基于评分的行动:
- 80-100: 批准
- 60-79: 有条件批准
- 40-59: 需要补救计划
- < 40: 不合作
1. 检测与告警
↓
2. 分类与分级
- 确定严重性 (P0-P3)
- 分配给响应人员
↓
3. 调查
- 收集证据
- 分析日志 (SIEM)
- 确定范围
↓
4. 遏制
- 隔离受影响的系统
- 阻止恶意 IP/域名
- 禁用被入侵的账户
↓
5. 根除
- 移除恶意软件
- 修复漏洞
- 为系统打补丁
↓
6. 恢复
- 从备份恢复
- 验证系统完整性
- 返回生产环境
↓
7. 事后审查
- 记录时间线
- 根本原因分析
- 更新手册
- 实施改进
↓
8. 报告
- 执行摘要
- 监管通知 (如需要)
- 利益相关者沟通
1. 资产发现
- 扫描网络寻找资产
- 维护资产清单
↓
2. 漏洞扫描
- 认证扫描
- 非认证扫描
- 基于代理的监控
↓
3. 评估与验证
- 验证发现结果
- 移除误报
- 添加业务背景
↓
4. 优先级排序
- 应用 CVSS + 背景
- 分配严重性 (P0-P3)
- 创建修复工单
↓
5. 修复
- 为系统打补丁
- 应用补偿性控制措施
- 更新配置
↓
6. 验证
- 重新扫描以确认修复
- 更新漏洞状态
↓
7. 报告
- 指标仪表板
- 执行报告
- 趋势分析
1. 安排审查 (季度)
↓
2. 生成访问报告
- 按角色的用户访问
- 特权账户
- 服务账户
- 孤立账户
↓
3. 分发给经理
- 每位经理审查其团队
- 认证适当的访问权限
↓
4. 审查与认证
- 批准合法的访问权限
- 标记不适当的访问权限
- 识别孤立账户
↓
5. 补救
- 撤销未批准的访问权限
- 禁用孤立账户
- 更新 RBAC 分配
↓
6. 记录与报告
- 认证完成率
- 进行的访问变更
- 合规证据
1. 确定范围 (审计前 3-4 个月)
- 定义范围内的系统
- 选择信任服务标准
- 聘请审计师
↓
2. 差距评估 (审计前 2-3 个月)
- 将控制措施映射到要求
- 识别控制措施差距
- 创建补救计划
↓
3. 准备就绪 (审计前 1-2 个月)
- 实施缺失的控制措施
- 记录策略/程序
- 进行模拟审计
↓
4. 证据收集 (持续进行)
- 自动化证据收集
- 组织证据库
- 准备控制措施说明
↓
5. 审计启动
- 向审计师提供证据
- 响应请求
- 安排访谈
↓
6. 现场工作 (4-6 周)
- 审计师测试控制措施
- 提供额外证据
- 处理发现结果
↓
7. 报告发布
- 审查报告草案
- 处理任何例外情况
- 接收最终的 SOC2 报告
↓
8. 持续监控
- 监控控制措施有效性
- 为下一个审计周期做准备
每周安装次数
411
仓库
GitHub Stars
23.5K
首次出现
2026 年 1 月 21 日
安全审计
安装于
opencode327
gemini-cli318
codex304
claude-code299
github-copilot293
cursor282
Apply multiple layers of security controls so that if one fails, others provide protection. Never rely on a single security mechanism.
Never trust, always verify. Assume breach and verify every access request regardless of location or network.
Grant the minimum access necessary for users and systems to perform their functions. Regularly review and revoke unused permissions.
Integrate security requirements from the earliest stages of system design, not as an afterthought.
Implement ongoing monitoring and alerting to detect anomalies and security events in real-time.
Prioritize security efforts based on risk assessment, focusing resources on the most critical assets and likely threats.
Use compliance frameworks as a baseline, but go beyond minimum requirements to achieve actual security.
Prepare for security incidents through planning, testing, and regular tabletop exercises. Assume compromise will occur.
Objective : Understand current security posture and compliance requirements
Activities :
Deliverables :
Objective : Design secure systems and architectures
Activities :
Deliverables :
Objective : Deploy security controls and harden systems
Activities :
Deliverables :
Objective : Continuously monitor for threats and anomalies
Activities :
Deliverables :
Objective : Respond to security incidents and recover operations
Activities :
Deliverables :
Objective : Validate compliance and continuously improve security
Activities :
Deliverables :
When to use : Evaluating security risks and prioritizing mitigation efforts
Process :
1. Identify Assets
- What systems, data, and services need protection?
- What is the business value of each asset?
- Who are the asset owners?
2. Identify Threats
- What threat actors might target these assets? (nation-state, cybercriminals, insiders)
- What are their motivations? (financial gain, espionage, disruption)
- What are current threat trends?
3. Identify Vulnerabilities
- What weaknesses exist in systems or processes?
- What security controls are missing or ineffective?
- What are known CVEs affecting your systems?
4. Calculate Risk
Risk = Likelihood × Impact
Likelihood scale (1-5):
1 = Rare (< 5% chance in 1 year)
2 = Unlikely (5-25%)
3 = Possible (25-50%)
4 = Likely (50-75%)
5 = Almost Certain (> 75%)
Impact scale (1-5):
1 = Minimal (< $10K loss, no data breach)
2 = Minor ($10K-$100K, limited data exposure)
3 = Moderate ($100K-$1M, significant data breach)
4 = Major ($1M-$10M, extensive data breach, regulatory fines)
5 = Catastrophic (> $10M, business-threatening)
Risk Score = Likelihood × Impact (max 25)
5. Prioritize Risks
- Critical: Risk score 15-25 (immediate action)
- High: Risk score 10-14 (action within 30 days)
- Medium: Risk score 5-9 (action within 90 days)
- Low: Risk score 1-4 (monitor and accept)
6. Determine Risk Response
- Mitigate: Implement controls to reduce risk
- Accept: Document acceptance if risk is within tolerance
- Transfer: Use insurance or third-party services
- Avoid: Eliminate the activity that creates risk
Output : Risk register with prioritized risks and mitigation plans
When to use : Choosing appropriate security controls for identified risks
Framework : Use NIST CSF categories or CIS Controls
NIST CSF Functions:
1. Identify (ID)
- Asset Management
- Risk Assessment
- Governance
2. Protect (PR)
- Access Control
- Data Security
- Protective Technology
3. Detect (DE)
- Anomalies and Events
- Security Monitoring
- Detection Processes
4. Respond (RS)
- Response Planning
- Communications
- Analysis and Mitigation
5. Recover (RC)
- Recovery Planning
- Improvements
- Communications
Control Types:
- Preventive: Stop incidents before they occur (MFA, firewalls, encryption)
- Detective: Identify incidents when they occur (SIEM, IDS, log monitoring)
- Corrective: Fix issues after detection (patching, incident response)
- Deterrent: Discourage attackers (security policies, warnings)
- Compensating: Alternative controls when primary controls aren't feasible
Selection Criteria:
1. Does it address the identified risk?
2. Is it cost-effective? (Control cost < Risk value)
3. Is it technically feasible?
4. Does it meet compliance requirements?
5. Can we maintain and monitor it?
When to use : Determining which compliance frameworks to implement
Decision Tree :
What type of organization are you?
├─ SaaS/Cloud Service Provider
│ ├─ Selling to enterprises? → SOC2 Type II (required)
│ ├─ International customers? → ISO27001 (strongly recommended)
│ ├─ Handling health data? → HIPAA + HITRUST
│ └─ Handling payment cards? → PCI-DSS
├─ Healthcare Provider/Payer
│ ├─ U.S.-based → HIPAA (required)
│ ├─ International → HIPAA + GDPR
│ └─ Plus: HITRUST for comprehensive framework
├─ Financial Services
│ ├─ U.S. banks → GLBA, SOX (if public)
│ ├─ Payment processing → PCI-DSS (required)
│ ├─ International → ISO27001, local regulations
│ └─ Plus: NIST CSF for framework
├─ E-commerce/Retail
│ ├─ Accept credit cards → PCI-DSS (required)
│ ├─ EU customers → GDPR (required)
│ ├─ California customers → CCPA
│ └─ B2B sales → SOC2 Type II
└─ General Enterprise
├─ Selling to enterprises → SOC2 Type II
├─ Want broad recognition → ISO27001
├─ Government contracts → FedRAMP, NIST 800-53
└─ Industry-specific → Check sector regulations
Multi-Framework Strategy:
- Start with: SOC2 or ISO27001 (choose one as foundation)
- Add: Data privacy regulations (GDPR, CCPA) as needed
- Layer on: Industry-specific requirements
When to use : Triaging and responding to security incidents
Severity Levels :
P0 - Critical (Immediate Response)
- Active breach with data exfiltration occurring
- Ransomware encryption in progress
- Complete system outage of critical services
- Unauthorized access to production databases
- Response: Engage CIRT immediately, executive notification, 24/7 effort
P1 - High (Response within 1 hour)
- Confirmed malware on critical systems
- Attempted unauthorized access to sensitive data
- DDoS attack affecting availability
- Significant vulnerability with active exploits
- Response: Engage CIRT, manager notification, work until contained
P2 - Medium (Response within 4 hours)
- Malware on non-critical systems
- Suspicious account activity
- Policy violations with security impact
- Vulnerability requiring patching
- Response: Security team investigation, business hours
P3 - Low (Response within 24 hours)
- Failed login attempts (below threshold)
- Minor policy violations
- Informational security events
- Response: Standard queue, document findings
Classification Factors:
1. Data confidentiality impact (PHI, PII, financial, IP)
2. System availability impact (revenue, operations)
3. Data integrity impact (corruption, unauthorized changes)
4. Number of affected systems/users
5. Regulatory reporting requirements
When to use : Prioritizing vulnerability remediation
Framework : Enhanced CVSS with business context
Base CVSS Score × Business Context Multiplier = Priority Score
CVSS Severity Ranges:
- Critical: 9.0-10.0
- High: 7.0-8.9
- Medium: 4.0-6.9
- Low: 0.1-3.9
Business Context Multipliers:
- Internet-facing production system: 2.0×
- Internal production system: 1.5×
- Systems with sensitive data: 1.5×
- Development/test environment: 0.5×
- Active exploit in the wild: 2.0×
- Compensating controls in place: 0.7×
Priority Levels:
- P0 (Critical): Score ≥ 14 → Patch within 24-48 hours
- P1 (High): Score 10-13.9 → Patch within 7 days
- P2 (Medium): Score 6-9.9 → Patch within 30 days
- P3 (Low): Score < 6 → Patch within 90 days or accept risk
Additional Considerations:
- Can the system be isolated/segmented?
- Are there effective detective controls?
- What is the patching complexity/risk?
- Is there a vendor patch available?
When to use : Evaluating security risks of vendors and partners
Assessment Framework :
1. Categorize Vendor Risk Level
Low Risk (Minimal assessment):
- No access to systems or data
- Limited integration
- Non-critical service
→ Simple questionnaire
Medium Risk (Standard assessment):
- Limited system access
- Non-sensitive data access
- Important but not critical service
→ Security questionnaire + evidence review
High Risk (Comprehensive assessment):
- Production system access
- Sensitive data processing
- Critical service dependency
→ Full assessment + audit reports + pen test
Critical Risk (Extensive assessment):
- Full production access
- PHI/PII processing
- Business-critical dependency
→ On-site audit + continuous monitoring + SLA
2. Assessment Components
For Medium/High/Critical vendors:
□ Security questionnaire (SIG, CAIQ, or custom)
□ Compliance certifications (SOC2, ISO27001)
□ Insurance certificates (cyber liability)
□ Security policies and procedures
□ Incident response plan
□ Disaster recovery/business continuity plan
□ Data processing agreement (DPA)
□ Penetration test results (for high/critical)
□ Right to audit clause in contract
3. Ongoing Monitoring
- Annual reassessment
- Monitor for breaches/incidents
- Review security updates and patches
- Track compliance certification renewals
- Conduct periodic audits (for critical vendors)
4. Vendor Risk Score
Calculate score (0-100):
- Security maturity: 40 points
- Compliance certifications: 20 points
- Incident history: 15 points
- Financial stability: 15 points
- References and reputation: 10 points
Action based on score:
- 80-100: Approved
- 60-79: Approved with conditions
- 40-59: Requires remediation plan
- < 40: Do not engage
1. Detection & Alert
↓
2. Triage & Classification
- Determine severity (P0-P3)
- Assign to responder
↓
3. Investigation
- Gather evidence
- Analyze logs (SIEM)
- Determine scope
↓
4. Containment
- Isolate affected systems
- Block malicious IPs/domains
- Disable compromised accounts
↓
5. Eradication
- Remove malware
- Close vulnerabilities
- Patch systems
↓
6. Recovery
- Restore from backups
- Verify system integrity
- Return to production
↓
7. Post-Incident Review
- Document timeline
- Root cause analysis
- Update playbooks
- Implement improvements
↓
8. Reporting
- Executive summary
- Regulatory notification (if required)
- Stakeholder communication
1. Asset Discovery
- Scan network for assets
- Maintain asset inventory
↓
2. Vulnerability Scanning
- Authenticated scans
- Unauthenticated scans
- Agent-based monitoring
↓
3. Assessment & Validation
- Validate findings
- Remove false positives
- Add business context
↓
4. Prioritization
- Apply CVSS + context
- Assign severity (P0-P3)
- Create remediation tickets
↓
5. Remediation
- Patch systems
- Apply compensating controls
- Update configurations
↓
6. Verification
- Rescan to confirm fix
- Update vulnerability status
↓
7. Reporting
- Metrics dashboard
- Executive reports
- Trend analysis
1. Schedule Review (Quarterly)
↓
2. Generate Access Reports
- User access by role
- Privileged accounts
- Service accounts
- Orphaned accounts
↓
3. Distribute to Managers
- Each manager reviews their team
- Certify appropriate access
↓
4. Review & Certify
- Approve legitimate access
- Flag inappropriate access
- Identify orphaned accounts
↓
5. Remediation
- Revoke unapproved access
- Disable orphaned accounts
- Update RBAC assignments
↓
6. Document & Report
- Certification completion rate
- Access changes made
- Compliance evidence
1. Scoping (3-4 months before)
- Define in-scope systems
- Select Trust Service Criteria
- Engage auditor
↓
2. Gap Assessment (2-3 months before)
- Map controls to requirements
- Identify control gaps
- Create remediation plan
↓
3. Readiness (1-2 months before)
- Implement missing controls
- Document policies/procedures
- Conduct mock audit
↓
4. Evidence Collection (Ongoing)
- Automate evidence gathering
- Organize evidence repository
- Prepare control narratives
↓
5. Audit Kickoff
- Provide evidence to auditor
- Respond to requests
- Schedule interviews
↓
6. Fieldwork (4-6 weeks)
- Auditor tests controls
- Provide additional evidence
- Address findings
↓
7. Report Issuance
- Review draft report
- Address any exceptions
- Receive final SOC2 report
↓
8. Continuous Monitoring
- Monitor control effectiveness
- Prepare for next audit cycle
Weekly Installs
411
Repository
GitHub Stars
23.5K
First Seen
Jan 21, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykPass
Installed on
opencode327
gemini-cli318
codex304
claude-code299
github-copilot293
cursor282
多阶段Dockerfile最佳实践指南:构建更小更安全的容器镜像
8,900 周安装