应用层的渗透测试和漏洞扫描相当于对应用整体安全的一个检测机制，在安全问题引入之后，通过安全测试和漏洞扫描发现这些问题，推进修改。在安全管理维护方面，最经常处理的是CVE漏洞，CVE漏洞通常是一些隐藏较深、有一定修复难度的问题。对负责业务开发和业务运维的工程师来说，由于接触应用层安全问题的机会不多，仅有的几次机会也是对CVE漏洞的修复，修复的方案往往也是通过版本及第三方库的升级来完成的。长时间的操作过程造成了对应用安全处理机制的两个错误理解，一是认为安全问题是由外部安全防护机制来处理的，二是认为安全问题不太容易引入。
对安全问题的这两个印象实际上是不对的，特别是在云原生环境下，由于疏忽很容易引入安全漏洞。拿一个例子来看，一个容器中的进程如果以root身份运行，那么这个进程在主机操作系统内部也是root身份的，这个程序容易被利用并通过SUID扩大攻击范围；或者有些时候，由于错误地配置了网络策略，业务接口向平台中的所有业务应用开放，破坏了业务的隔离性。这些问题在实际应用中经常发生。
由于云原生业务应用的运行环境已经不同于传统业务应用场景，在传统业务应用场景下，安全管控主要依赖网络边界设备，比如防火墙、IDS/IPS、WAF等。云原生业务系统运行在云化的环境中，网络边界普遍已经虚拟化和模糊化。另外，云原生环境有大量的多租户共享以及多业务应用共用的情况，各业务系统需要在代码、配置和技术选型使用上注意安全问题。如果不遵守一个好的安全规范，日积月累的小安全问题会让业务系统漏洞百出。在常规情况下也许业务系统能够稳定运行，在扩展性和性能等方面表现良好，但是一旦遇到攻击，很容易就会出现严重的安全事故，比如数据泄露、资源泄露或者遭受网络欺诈，造成严重后果。所以云原生应用在开发流程执行过程中就需要确立好安全规范，并把安全规范的执行检查嵌入到DevOps流程中。
安全规范需要考虑平台安全使用规范、容器镜像安全规范、云原生应用安全规范、安全审计规范这四个领域。这四个领域中安全规范的作用和目的如下。
1）平台安全使用规范：规定平台层（包括主机、Kubernetes集群）的配置和使用规则。
云原生平台是应用运行的基础，安全工程师的一个重要职责是维护平台的安全。平台安全建设的约束和规范在应用开发流程中可以体现的点并不多，主要是在用户和文件权限及Kubernetes平台配置。
2）容器镜像安全规范：规定应用镜像打包规范，约束使用的基础镜像以及基础镜像的使用方法。
- 只能使用指定的容器基础镜像（如alpine的固定版本）。
- Dockerfile中不能包含敏感信息（比如密码等）。
- 需通过USER命令指定容器进程的启动用户，不能以默认的root身份启动。
- 镜像不能挂载包括/etc、/bin、/root等路径在内的系统关键路径。
- 发布的镜像需通过镜像扫描平台进行安全扫描。
- 非特殊情况，不允许在基础镜像的基础上再下载扩展软件包。
- 某些情况下，安装扩展软件包时，需通过安全工程师来操作，安全的软件包需精简，去除无用的附属文件（如debug工具、帮助文件等）。
3）云原生应用安全规范：规定Pod的定义规则、namespace的隔离规则以及各应用之间的访问规则；还包括应用在架构上的安全定义规则。
云原生应用安全规范的内容较多，包括应用中间件的选型和使用、应用Pod声明文件包含的必要配置、应用Pod之间的隔离策略、Security Context和Pod Security Policy的使用规范以及平台服务账号及其角色绑定的配置规范等。
4）安全审计规范：规定应用的操作日志、与安全相关的应用运行日志的打印规范。
安全审计规范中定义了应用操作日志、与安全相关的运行日志及运行事件的输出规范，主要包括以下内容。
- 用户对资源的操作和管理需记录操作日志，操作日志的信息字段需记录操作源IP等关键字段。
- Web层接口的调用入口及出口需记录调用日志，调用日志的级别需为WARN。调用日志需标记出调用时间、输入参数和能够标记调用用户的字段信息。
- 应用日志中不能输出用户的隐私信息（比如用户密码等）。
- 应用日志需对应用异常情况进行捕获，并输出应用运行的整体情况日志，如在线程池满的时候，输出线程总数及请求队列的统计信息。
- 需开启kube-apiserver审计，记录平台的事件信息。
平台以及应用层规范的制定主体是安全工程师。安全工程师除了提出和制定安全流程规范外，还负责在DevSecOps流水线中配置自动化的安全规范检查机制，将安全的检查工作融入日常的开发流程中，利用云平台的自动化机制来实现自动化的持续安全。
