SDL浅析

软件开发生命周期

（SDLC) 软件开发生命周期（SDLC, software development life cycle)，包含软件从开始到发布的不同阶段，旨在提高待开发软件的质量和效率。常划分为以下六个阶段：需求分析 (Analysis)，设计 (Design)，开发 (Implementation)，测试 (Testing)，部署 (Deployment) 和维护 (Maintenance)。

SDLC阶段

1.需求分析(Analysis): 需求分析是软件开发过程中最重要和基础的环节。该阶段所有利益相关方(如：产品经理、业务需求方、开发者等)就软件需求(解决哪些问题)及可行性(能否被解决)进行讨论，并将所搜集到信息记录软件需求文档中(SRS, Software Requirement Specification)。
2.产品设计(Design): 根据上一阶段记录的软件需求文档，设计出能满足相关需求的体系架构。该阶段定义交互和数据透传流程。
3.软件开发(Implementation): 该阶段，开发人员根据设计开发和实现软件。后端工程师负责构建数据库结构和其他必要组件。前端工程师负责用户界面设计，并负责与后端架构对接。该阶段，用户指南、源代码的注释等配套文档将有助于提升代码质量，及降低后期软件使用和维护成本。
4.测试(Testing): 软件正式上线前，为避免软件存在问题和确保软件达到预期效果，相关人员将进行测试。该阶段既可以与开发同时进行，也可以在开发阶段结束时再开展。
5.部署(Deployment): 即软件正式上线阶段，安装指南、系统用户指南等相关部署文档将有效辅助软件部署。该阶段常采用灰度开放的方式逐步完成，避免软件存在问题带来生产事故。
6.维护(Maintenance): 软件正式上线后，对报告的测试期间未能发现错误进行修复。同时，通过搜集使用者反馈，进一步优化软件设计，提升使用者体验。

DevSecOps

在传统的软件开发中，安全性测试是一个独立于软件开发生命周期（SDLC）的过程。安全团队只有在构建软件后才能发现安全漏洞。这导致仍有大量隐藏漏洞遗留，同时也增加了安全风险。

DevSecOps是将安全从软件开发生命周期的早期阶段就融入到开发流程中，强调的是在软件开发过程中持续集成和自动化安全实践。它通过紧密协作来确保安全、开发和运维团队能够更有效地一起工作，实现快速、安全、可靠的软件交付。

DevSecOps 是在软件开发过程的每个阶段集成安全测试的实践。它包括鼓励开发人员、安全专家和运营团队之间协作的工具和流程，以构建能够承受现代威胁的软件。此外，它还确保诸如代码审查、架构分析和渗透测试等安全保障活动能够参与到开发工作当中。

简单来说，SDLC为软件开发的流程提供了一个基础框架，而DevSecOps则是在这个框架内加入了安全元素，两者共同确保软件产品不仅功能强大，而且安全可靠。

安全开发生命周期（SDL)

安全开发的重要性

随着信息技术的迅速发展，软件开发已成为企业实现业务目标的关键手段。然而，软件开发过程中存在的安全风险不容小觑。从身份盗窃到数据泄露，这些风险可能对企业的声誉和财务状况造成严重影响。如何有效控制软件安全开发，以确保企业数据安全，已成为企业管理者面临的重要问题。

安全开发的概念

SDL：Security Development Lifecycle（安全开发生命周期）是由微软提出并应用的从安全角度指导软件开发过程的管理模式。

SDL是一个安全保证（Security Assurance）的过程，一个帮助开发人员构建更安全的软件和解决安全合规要求的同时降低开发成本的软件开发过程。其重点是软件开发，它在开发的所有阶段都引入了安全和隐私的原则，旨在开发出安全的软件应用。

安全开发的目标

（1）降低部署代码中的漏洞数量这是确保软件安全的基础。每一个漏洞都可能成为黑客攻击的入口，给企业带来巨大的风险。

（2）开发安全的软件安全的软件应能抵御各种常见的安全威胁，如注入攻击、数据泄露等。

（3）指导开发团队开发安全的软件为开发团队提供安全开发的指导，使他们在开发过程中能够遵循安全原则，避免因疏忽或缺乏知识而引入安全隐患。

（4）为企业内软件安全开发提供标准化的流程和工具标准化的流程有助于提高开发效率和质量，而合适的工具可以帮助开发人员更轻松地检测和修复安全问题。

（5）通过评估和度量证明企业的软件安全能力成熟度企业通过完整的流程、完整的工具、完整的制度和完整的审计来构建自己的软件安全能力成熟度。

安全开发的流程

建立安全开发指导体系是确保软件开发过程中安全性的关键步骤。该指导体系包括对各个开发阶段的详细安全要求和最佳实践的规定，涵盖需求调研、开发、测试、部署和发布等环节。

（1）调研阶段

需求人员需在需求调研阶段按照安全需求评审表收集客户安全要求，设计需求过程强调安全需求点，加强研发人员对此功能安全的侧重点。

（2）开发阶段

开发人员在编码阶段需要具备对常见漏洞的识别和修复能力，例如跨站脚本（XSS）、SQL注入、跨站请求伪造（CSRF）、敏感数据的加密处理等。

（3）测试阶段

采用安全开发工具（如静态代码分析、动态分析等），自动化检测并修复安全问题。

（4）部署阶段

评估开发质量，对应用系统进行安全测试、渗透测试等，对数据进行数据安全测试、个人信息保护方面的检测，对配置库、运行环境进行安全检查。

（5）发布阶段

需要进行等保测评、密码测评、风险评估等方面的合规性验证，定期或不定期进行渗透测试。

安全开发规范

编码安全

输入验证

概述

任何来自客户端的数据,如URL和参数、HTTP头部、 Javascript戓其他嵌入代码提交的信息，都属于不可信数据。在应用外部边界或内部每个组件或功能边界，都将其当做潜在的恶意输入来校验

白名单

不可信数据可以设定白名单校验的，应接受所有和白名单匹配的数据，并阻止其他数据

黑名单

不可信数据中包含不良输入字符时,如空字节(%00)、换行符(%0d,%0a, )、路径字符(../ 或 ..)等,建议直接阻止该数据,若需要接受该数据,则应做不同方式的净化处理

规范化

不可信数据的净化和校验前翯进行规范化,如将目录遍历(./或)等相对路径转化成绝对路径URL解码等。

净化

不可信数据需实施各种净化处理时,应彻底删除恶意字符,只留下已知安全的字符,或者在处理前对它们进行适当编码或"转义",如数据输出到应用页面时对其进行HTML编码可防止脚本攻击

合法性校验

不可信数据的合法性校验包括：数据类型如字符。数字、日期等特征;数据范國;数据长度等。

防范SQL注入

不可信数据进入后端数据库操作前,建议使用正角的参数化查询来处理,避免出现SQL注入。

文件校验

不可信数据为解压缩的文件时,如果文件位于服务目录外或文件大小超过限制,应拒绝处理。

访问控制

不可信数据通过上述校验后,还应确认所提交的内容是否与用户的身份匹配,避免越权访问。

输出验证

概述

考虑目标编译器的安全性，对所有输出字符进行正确编码。

编码场景

不可信数据输出到前后端页面时,根据输出场景对其进行相关编码,如HTML实体编码、UR编码。

净化场景

针对操作系统命令、SQL和LDAP查询,净化所有输出的敏感信息,如银行卡、手机号、系统信息等。

SQL注入

概述

用户的输入进入应用程序的SQL操作前,对输入进行合法性校验。

参数化处理

用参数化查询(PHP用PDO,Java用 PreparedStatement,C#用 Sqlparameter)方法对敏感字符如"进行转义,然后再进行SQL操作。

最小化授权

为每个应用配置最小化数据库操作权限,禁止用管理员权限进行数据库操作,限制操作连接数。

敏感数据加密

敏感信息都采用了加密、哈希或混淆等方式进行保密存储,降低可能漏洞带来的数据泄露风险。

禁止错误回显

禁止系统开启 Debug模式或异常时返回包含敏感信息的提示,建议使用自定义的错误信息模板异常信息应存放在日志中用于安全审计。

XSS跨站

输入校验

对输入的数据进行过滤和转义,包含但不限于<>"9%0&+"等危险特殊字符。输出编码输入数据输出到不同场景中进行不同形式的编码,如输出到HTML标签中则进行HTML编码输出到URL中则进行URL编码,输出到JS中则行 Script编码,输出到 Stylet中则进行CSs编码。

XML注入

输入校验

在XML文档内部或外部引用数据时,过滤用户提交的参数,如<、>&等特殊字符。禁止加载外部实体,禁止报错。

输出编码

建议对XML元素属性或者内容进行输出转义。

CSRF跨站请求伪造

Token使用

在重要操作的表单中增加会话生成的 Token字段次一用,提交后在服务端校验该字段。

二次验证

在关键表单提交时,要求用户进行二次身份验证如密码、图片验证码、短信验证码等。

Referer验证

检验用户请求中 Referer:字段是否存在跨域提交的情况。

逻辑安全

身份验证

概述

所有对非公开的网页和资源的访问,必须在后端服务上执行标准的、通用的身份验证过程。

提交凭证

用户凭据必须经过加密且以POST方式提交,建议用HTPS协议来加密通道、认证服务端。

错误提示

安全地处理失败的身份校验,如使用"用户名或密码错误"来提示失败,防止泄露过多信息。

异常处理

登录入口应具有防止暴力或撞库猜解(利用已泄露的密码字典进行批量登录尝试)的措施,超过1次验证失败自动启用图灵测试,超过多次验证失败自动启用账户锁定机制限制其访问。

二次验证

在执行关键操作(如账户密码修改、资料更新、交易支付等)时,先启动图灵测试,再对用户身份进行二次验证。交易支付过程还应该形成完整的证据链,待交易数据应经过发起方数字签名。

多因子验证

高度敏感或核心的业务系统,建议使用多因子身份验证机制,如短信验证码、软硬件 Token等。

短信验证

验证码生成

复杂度至少6位数字或字母,一次一用,建议有效期不超过180秒。

验证码限制

前后端设置用户获取频率为60秒一次,建议每个用户每天获取的短信最多10条。

安全提示

增加安全提示:至少含本次操作的功能、验证码发送编号、是否是个人自己操作的风险等信息。

凭证校验

禁止在响应中返回验证码,服务器端同时校验密码、短信验证码等凭证信息,防止出现多阶段认证绕过的漏洞。

图灵测试

验证码生成

复杂度至少4位数字或字母,或者采用拼图等验证方式,一次一用,建议有效期不超过180秒。

验证码使用

建议从用户体验和安全角度出发,可设计为当用户输错1次密码后自动弹出验证码输入框验证。

验证码校验

禁止在响应中返回验证码,验证码校验应在服务端进行。

密码管理

密码设置

密码设置时,应该满足8位及以上长度,含大小写字母、数字及特殊字符等的要求。用户密码设置必须经过后端验,不允许设置不满定复杂度要求的感密码。

密码存储

用户密码存储时,应采用哈希算法(如SHA1)计算用户密码和唯一随机盐值(Salt)的摘要值保存其摘要和Sat值,建议分开存储这两个值。

密码修改

用户修改密码时,修改操作需要通过手机号或者邮箱地均进行一次身份验证。密码变更时,应短信或者邮件通知如用户是否是本人操作,告知其安全风险。

密码找回

用户密码找回时,后端需要对注册手机号或邮箱进行二次验证,验证码和验证链接应发送至预先注册的地址,并设置有效期以防止暴力破解。密保问题,应当支持尽可能随机的问题提问。在多个验证操作中,要对各验证机制进行排序,以防出现跳过前面验证机制直接到最后步认证的安全风险。

密码使用

应用开发中禁止设置万能密码、硬编码明文的密码、使用数据库管理员账户操作、不同用户公用账户操作或者将密码输出到日志文件或者控制台。

会话安全

防止会话劫持

在应用程序进行身份验证时,建议持续使用HTTPS连接,认证站点使用HTTPS协议。如果连接是从防止会话劫持HTTP跳转到HTTPS,需要重新生成会话标识符。禁止在HTTP和HTTPS之间来回转换,这可能会导致会话被劫持。

会话标识符安全

设置会话 Cookie时,正确设置" Httponly'属性(禁止程序加5脚本等读取 Cookie信息)" Secure'属性(禁Cookie安全设置止Cookie通过HTTP连接传递到服务器端进行验证);" Domain"属性(跨域访问时可指定的授权访问域名),"Path"属性(授权可访问的目录路径)。

Cookie安全设置

会话标识符应放置在HTP或HTPS协议的头信息安全中,禁止以GET参数进行传递、在错误信息和日志中记录会话标识符。

防止CSRF攻击

服务器端执行了完整的会话管理机制,保证每个会防止CSRF话请求都执行了合法的身份验证和权限控制,防止攻击发生跨站点请求伪造(CSRF)漏洞。

会话有效期

会话应在平衡风险和功能需求的基础上设置有效期。定期生成一个新的会话标识符并使上一个会话会话有效期标识符失效,这可以缓解那些因原会活标识符被盗而产生的会话劫持风险。

会话注销

注销功能应用于所有受身份验证保护的网页,用户会话注销登出后应立即清理会话相关信息,终止相关的会话连接。

访问控制

控制方法

将访问控制的逻辑代码与应用程序其他代码分开服务端根据会话标识来进行访问控制管理。

控制管理

限制只有授权的用户才能访问受保护的URL、文件、服务、应用数据、配置、直接对象引用等。

接口管理

限制只有授权的外部应用程序或接口才能访问受保护的本地程序或资源等。

权限变更

当权限发生变更时,应记录日志,并通知用户是否是本人操作,告知存在的安全风险。

文件上传安全

身份校验

进行文件上传时,在服务端对用户的身份进行合法性校验。

合法性校验

进行文件上传时,在服务端对文件属性进行合法性校验,白名单形式检查文档类型(如文件的后缓名、文件头信息校验等)和大小(图片校验长、宽和像素等)。

存储环境设置

进行文件保存时,保存在与应用环境独立的文档服务器中(配置独立域名),保存的目录权限应设置为不可执行。

隐藏文件路径

进行文件保存时,成功上传的文件需要进行随机化重命名,禁止给客户端返回保存的路径信息。

文件访问设置

进行文件下载时,应以二进制形式下载,建议不提供直接访问(防止木马文件直接执行)。

接口安全

网络限制

调用方网络限制,比如通过防火墙、主机host和Nginx deny等技术措施进行校验。

身份认证

调用方身份认证,比如key、 secret、证书等技术措施进行校验,禁止共享凭证。

完整性校验

调用的数据安全,对全部参数使用SHA1等摘要运算进行数字签名,识别数据被篡改。

合法性校验

调用的参数检查,如参数是否完整,时间戳和Token是否有效,调用权限是否合法等。

可用性要求

调用的服务要求,调用满足等幂性即保持数据一致性,对调用频率和有效期进行限制。

异常处理

调用的异常处理,调用行为实时检测,发现异常及时阻拦。

数据安全

敏感信息

敏感信息传输

敏感信息传输时,禁止在GET请求参数中包含敏感信息,如用户名、密码、卡号等。建议为所有敏感信息采用TSL加密传输。

客户端保存

客户端保存敏感信息时,禁止其表单中的自动填充功能、以明文形式保存敏感信息

服务端保存

服务端保存敏感信息时,禁止在程序中硬编码敏感信息,明文存储用户密码、身份证号、银行卡号、持卡人姓名等敏感信息,临时写入内存或文件中的敏感数据,应及时清除和释放

敏感信息维护

敏感信息维护时,禁止将源码或SQL库上传到开源平台或社区,如 Github、开源中国等。

敏感信息展示

敏感信息展示时,如果是展示在web页面上,应在后端服务器上进行敏感字段的脱敏处理。

日志规范

记录原则

确保日志记录包含了重要的应用事件,但禁止保存敏感信息,如会话标识,账户密码、证件等。

事件类型

记录所有的身份验证、访问操作、数据变更、关键操作、管理功能、登出记录等事件。

事件要求

日志一般会记录每个事件的发生时间、发出请求的IP地址和用户账户(如果已通过验证)。日志保护日志受到严格保护,避免未授权的读取或写入访问。

异常处理

容错机制

在应用实现时应包含完整的功能异常捕获机制，如try-catch块,典型位置:文件、网络、数据库、命令操作等。一旦出现异常,应该在日志中完整记录异常的发生时间、代码位置、报错详情、触发错误的可能用户等,重要系统的严重异常应该有报警的机制,及时通知系统运营者及时排查并修复题。

自定义错误信息

在生产环境下,应用程序不应在其响应中返回任何系统生成的消息或其他调试信息,配置应用服务器使其以自定义的方式处理无法处理的应用程序错误,返回自定义错误信息。隐藏用户信息禁止在系统异常时泄露用户的隐私信息,典型的有:身份信息、个人住址、电话号码、银行账号、通讯记录、定位信息等。

隐藏系统信息

禁止在系统异常时泄露系统的敏感信息(用户账户和密码、系统开发密钥、系统源代码、应用架构、系统账户和密码、网络拓扑等)。

异常状态恢复

方法发生异常时要恢复到之前的对象状态,如业务操作失败时的回滚操作等,对象修改失败时要恢复对象原来的状态,维持对象状态的一致性。

主机安全

I/O

操作共享环境文件安全

在多用户系统中创建文件时应指定合适的访问许可,以防止未授权的文件访问,共享目录中文件的读/写/可执行权限应该使用白名单机制,实现最小化授权。

数据访问

检查防止封装好的数据对象被未授权使用,设置合理的据缓存区大小以防止耗尽系统资源。

应用文件处理

应用程序运行过程中创建的文件,需设置问权限(读、写、可执行),临时文件使及时删除。

运行环境

最小化开放端口

关闭操作系统不需要的端口和服务。

后台服务管理

后台(如数据缓存和存储、监控、业务管理等)务限内部网络访问,开放在公网的必须设置身份验证和访问控制。

环境配置

使用安全稳定的操作系统版本、Web股务器软件各种应用框架、数据库组件等。

敏感代码处理

将客户端敏感代码(如软件包签名、用户名密码校验等)都放在o等软件包中防止篡改。

关闭调试通道

生产代码不包含任何调试代码或接口。

通信安全

配置网站的HTTPS证书或其它加密传输措施。

Java安全开发示例

此处仅举部分示例，详细可参考 https://github.com/Tencent/secguide/blob/main/Java%E5%AE%89%E5%85%A8%E6%8C%87%E5%8D%97.md

输入验证

输入验证（Input Validation）：在用户输入数据时，必须对其进行验证，以防止恶意用户输入恶意数据。例如，如果用户在表单中输入邮件地址，应该确保其格式正确且安全。

String email = request.getParameter("email");
if (email.matches("[a-zA-Z0-9]+@[a-zA-Z0-9]+\\.[a-zA-Z0-9]+")) {
    // 处理合法的邮件地址
} else {
    // 处理非法的邮件地址
}

XSS防御

跨站脚本攻击（Cross-Site Scripting，XSS）防御：XSS攻击是指攻击者通过在网站中注入恶意脚本来攻击用户的浏览器。为了防御XSS攻击，应该对用户输入的数据进行过滤和编码。

1
2
3

String userInput = request.getParameter("input");
String safeOutput = StringEscapeUtils.escapeHtml4(userInput);
response.getWriter().println(safeOutput);

防止SQL注入

1.预编译：SQL注入是指攻击者通过在网站中注入恶意SQL代码来攻击数据库，从而获取或篡改数据。为了防御SQL注入，应该使用预编译的SQL语句，或者使用参数化查询。

String username = request.getParameter("username");
String password = request.getParameter("password");

String sql = "SELECT * FROM users WHERE username = ? AND password = ?";
PreparedStatement statement = connection.prepareStatement(sql);
statement.setString(1, username);
statement.setString(2, password);

ResultSet resultSet = statement.executeQuery();

2.白名单过滤：对于表名、列名等无法进行预编译的场景，比如外部数据拼接到order by, group by语句中，需通过白名单的形式对数据进行校验，例如判断传入列名是否存在、升降序仅允许输入“ASC”和“DESC”、表名列名仅允许输入字符、数字、下划线等。

public String someMethod(boolean sortOrder) {
 String SQLquery = "some SQL ... order by Salary " + (sortOrder ? "ASC" : "DESC");`
 ...

会话管理和Cookie安全

1.防止会话劫持使用安全的会话管理机制，如SSL/TLS来加密传输的数据，并且设置cookie为Secure和HttpOnly。

1	response.addCookie(new Cookie("JSESSIONID", sessionId, "/", domain, false, "Strict", 86400, 256, true));

2.防止跨站点请求伪造（CSRF） CSRF攻击试图利用用户的登录会话来执行未授权的命令。使用CSRF令牌可以防止这种攻击。

@Override
protected void configure(HttpSecurity http) throws Exception {
   
    http.csrf().and()
        // ... other configurations
}

密码加密

使用安全的密码存储：为了保护用户密码，应该对其进行加密存储，以防止数据库泄露导致密码被恶意用户获取。使用较为复杂的加密方式（AES-CBC、AES-GCM、RSA、SHA-2、明文密码+随机盐多轮哈希处理），以防止攻击者对密码解密后进行爆破、撞库等恶意行为。

String password = request.getParameter("password");
String hashedPassword = BCrypt.hashpw(password, BCrypt.gensalt());

// 将hashedPassword存储到数据库中

实现角色基础的访问控制确保应用程序中的敏感操作需要适当的权限检查。可以使用Spring Security等框架来实现角色和权限的管理。

@PreAuthorize("hasRole('ADMIN')")
public void sensitiveOperation() {
   
    // ...
}

文件操作

1.文件类型限制：须在服务器端采用白名单方式对上传或下载的文件类型、大小进行严格的限制。仅允许业务所需文件类型上传，避免上传.jsp、.jspx、.class、.java等可执行文件。

String file_name = file.getOriginalFilename();
 String[] parts = file_name.split("\\.");
 String suffix = parts[parts.length - 1];
 switch (suffix){
     case "jpeg":
         suffix = ".jpeg";
         break;
     case "jpg":
         suffix = ".jpg";
         break;
     case "bmp":
         suffix = ".bmp";
         break;
     case "png":
         suffix = ".png";
         break;
     default:
         //handle error
         return "error";
 }

2.禁止外部文件存储于可执行目录禁止外部文件（如用户自行上传文件）存储于WEB容器的可执行目录，建议保存在专门的文件服务器中或限制目录的执行权限。

3.避免路径穿越如果文件路径、文件命名中拼接了不可行数据，需要判断文件名和文件路径参数是否存在 ../ 或 ..（WIN) 如存在判定路径非法并拒绝请求。

4.尽可能避免路径拼接文件目录避免外部参数拼接。保存文件目录建议后台写死并对文件名进行校验（字符类型、长度）。建议文件保存时，将文件名替换为随机字符串。

网络访问

避免直接访问不可信地址：服务器访问不可信地址时，禁止访问私有地址段及内网域名。

// 以RFC定义的专有网络为例，如有自定义私有网段亦应加入禁止访问列表。
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
127.0.0.0/8

建议通过URL解析函数进行解析，获取host或者domain后通过DNS获取其IP，然后和内网地址进行比较。对已校验通过地址进行访问时，应关闭跟进跳转功能。

1
2
3

httpConnection = (HttpURLConnection) Url.openConnection();

httpConnection.setFollowRedirects(false);

查询业务

1.返回信息最小化返回用户信息应遵循最小化原则，避免将业务需求之外的用户信息返回到前端。

2.个人信息脱敏在满足业务需求的情况下，个人敏感信息需脱敏展示,如： - 鉴权信息（如口令、密保答案、生理标识等）不允许展示 - 身份证只显示第一位和最后一位字符，如3****************1。 - 移动电话号码隐藏中间6位字符，如134******48。 - 工作地址/家庭地址最多显示到“区”一级。 - 银行卡号仅显示最后4位字符，如************8639

3.数据权限校验查询个人非公开信息时，需要对当前访问账号进行数据权限校验。 - 验证当前用户的登录状态。 - 从可信结构中获取经过校验的当前请求账号的身份信息（如：session）。禁止从用户请求参数或Cookie中获取外部传入不可信用户身份直接进行查询。 - 验当前用户是否具备访问数据的权限。

数据保护

1.使用HTTPS

2.敏感数据加密对于敏感数据，如信用卡、身份证等信息，使用强加密算法进行加密存储。

Cipher cipher = Cipher.getInstance("AES");
cipher.init(Cipher.ENCRYPT_MODE, secretKey);
byte[] encryptedData = cipher.doFinal(dataToEncrypt);

错误处理和日志记录

1.避免泄露敏感信息

确保错误信息不会泄露敏感数据，如堆栈跟踪或详细的系统信息。

try {
   
    // ... potentially unsafe operation
} catch (Exception e) {
   
    log.error("An error occurred", e);
    throw new GeneralSecurityException("An error occurred");
}

2.审计日志记录记录关键操作的审计日志，以便在发生安全事件时进行调查。

1	log.info("User {} logged in successfully", username);

References

https://learn.microsoft.com/zh-cn/compliance/assurance/assurance-microsoft-security-development-lifecycle

https://github.com/Tencent/secguide/blob/main/Java%E5%AE%89%E5%85%A8%E6%8C%87%E5%8D%97.md

https://github.com/javaweb-rasp/javaweb-secure-coding

https://mp.weixin.qq.com/s/pdoIAzBn95L8UwCbfXzjig

https://blog.csdn.net/Moooooonster/article/details/130779833

https://www.infoq.cn/article/rlk13kbkx40lddowsvhy

https://segmentfault.com/a/1190000044655532