本帖最后由 adminlily 于 2018-10-31 09:35 编辑 6 ]2 \5 T0 m0 M% u
, w# \) G$ X* p, I3 i/ ^. `各行各业的组织,无论规模大小,都会使用开源应用,眼下这种趋势有增无减。在开发阶段,将源代码嵌入软件中既经济、又高效。借助于其他资源,开发人员可以将更多的精力集中于组织的内部代码。但 DevSecOps 的问题不容忽视。: o; }: ~4 U5 g5 |2 m2 ~+ }6 T. V: ~( w
% E0 l1 O1 a% k4 [7 ?. @& y* q
: C1 Y" c1 e% |2 G# D* D
据GitHub调查,94%的受访者表示至少会时不时地使用开源应用,而81%的人则经常使用。实际上,82%的开发人员透露,所在单位接受使用开源软件,而84%的人被鼓励在应用中使用开源代码。 ) R a1 J6 z; I
) Z1 L1 U' z+ H! O* z/ w" D- g
虽然使用开源代码 还需要在持续交付中确保安全7 |! J& [8 O! X" N/ R* N( S
8 k# D9 \/ e7 z8 ?9 b
虽然开源部件可节约时间和成本,但其许可协议中均规定了相关责任。此外,在请求下载的开源软件中,有1/16的软件存在已知漏洞。 1 [4 M8 w, [" [
$ K/ R1 X: G n7 }3 h
在瀑布开发模式中,开源部件存在漏洞显然让人头疼,但远没有现在这么严重。敏捷开发速度快,每个周期结束都应该交付可用、安全的产品用于销售。在要求持续、敏捷开发的同时,如何才能保证解决方案中不存在开源漏洞呢? ! m& r m; j/ r, `: t" M; ?9 n$ x' I
0 s# c" q O0 r7 ?2 N
图 1 传统的非协调业务交付生命周期与现代持续应用安全测试方法对比 ( 来源 :Forrester,2016 年 5 月 3 日 .Amy DeMartine — 加速现代业务交付 )
, t4 A, b: n k- B" @
; c( Y; b- @6 d9 k% n" v! t$ _
坚持在开发阶段发现漏洞 强化安全测试 ~. e% H$ q- t0 Z. p- _
但开源代码呢?现在,这些代码在组织的产品代码中比私有代码还要常见。Gartner于2017年2月发布的应用安全测试魔力象限报告中提到“到2019年,80%的应用安全测试厂商将在其产品中包含软件构成分析,而当前这一比例为40%。” ' O. T) V+ E" ^- U
- |- l0 {( G" x3 U
这说明在仅仅两年时间中增长 40 个百分点 。正常的应用安全产品中除了静态分析安全测试(SAST)、动态分析安全测试(DAST)和交互式应用安全测试(IAST)方案外,再加入软件构成分析(SCA),这对客户来说意味着什么呢?总的来说,Gartner的预测表明,客户可能会利用厂商的方案包来测试自己的老旧、现代、移动或组合应用。 ( j, ~, I9 d4 S- ]) l
+ F N7 t9 R. s9 d2 \% F& c, D% p* d
% Y; b# C4 Z' ?8 @9 | S7 e
图 2 应用安全测试工具类型 ( 来源 :Forrester,2017 年 8 月 7 日 .Amy DeMartine — 厂商比较 : 应用安全测试 ) ( V$ \! a/ X- e1 m1 h; @) P
. [" {! {6 P! q2 Q
(小编,安全测试服务的相关介绍可参考: 你不要觉得渗透测试随便拿个工具就可以做了 要了解业务还需要给出解决方案 ) 防止代码出现漏洞只要三步
* s0 X. j- R5 `; {/ F* \' s- }
9 a; Q7 X. `/ f1 x7 \# [9 Y( S0 e9 s2 l1 e1 H
如今,应用安全工具越来越早地出现在软件开发生命周期(SDLC)中。最理想情况下,它们会与组织的构建工具绑定,若存在有漏洞的部件,构建就会失败,或者至少会通知相关漏洞部件的发布经理。 9 l; W3 M9 A7 Y' b+ v: ]) y' ]: w
+ A8 E8 R- \6 c& D% K4 j7 x
对于开发经理和首席安全官(CSO)来说,这样的日常做法能满足六个 DevOps 安全要求中的五项:自动化、速度、覆盖率、检测与修复。
9 K2 z. k/ Q. h
但第六个要求“预防”呢?这正是未来最佳实践要发挥作用的地方:让开发人员去防止有漏洞的开源部件进入到代码中。为此目的,安全主管应采取如下步骤: ; ?' }# _9 _7 y K8 Z/ `- I" y
. _# y/ D. v* k- k: Z e
1.定义需自动实施的开源策略。 理想情况下,可利用公司的SCA工具设置任何策略,包括安全漏洞严重性、许可团队、漏洞级别及入库年限。
/ `: ^7 B- o$ A; P
6 C! Z* N3 Q/ {( B, w r. N- \% z3 J: E* H, O, X
2.要求开发人员只下载安全部件。 使用浏览器扩展,在开发人员欲下载有漏洞的开源部件时,发出警告。! h P% I( M2 p9 X+ q0 z8 B
" I3 u3 F# N. B E" h; [# d4 D6 X* P7 j7 @$ [/ p2 Z4 Z: l
3.利用集体智慧 , 采用同类公司已实施过的策略 , 包括类似垂直行业(如健康和金融服务)开发者实施的策略。还可以利用相同规模组织实施过的策略。学习他人经验,占据主动,拒安全漏洞于代码之外。1 q8 z/ f5 Y/ M9 s* ^5 P: \
5 O' d0 B3 t, o
& Z; h" X5 b6 I精心规划 实践安全开发生命周期SDL 保证安全! S) A; u4 L \4 K* u3 L( j
3 V/ Y) J" k2 G4 m+ s1 s: g+ V/ F/ ?
持续交付与组合应用的安全性很快将成为日常活动。要确保下一步的最佳实践—能力最终左移至开发人员,防止安全漏洞进入到代码中。在这个方面绿盟科技已经总结并实践了一套安全开发生命周期SDL
1 S" I1 Q2 a% \ w1 B4 O) T* T
/ ?6 g! r3 Q8 t
* N4 G) o% z' U4 _# Y
我们不仅希望自己更少遇到风险,更希望自己遇到风险之后能够有足够强的能力应对。针对一个企业来说,开发人员应该通过安全培训来具备足够强的安全风险意识和安全开发能力。对于企业的安全管理,应该要具备一套健全的安全开发规范制度和系统上线运营安全流程。在一个互联网金融的项目上线之前,应该做好完善的安全准备,建立各个层面的安全防线,从项目的各个阶段引入安全控制,从源头上来避免安全风险。一个完善的开发项目应该引入SDL(Security Development Lifecycle,安全开发生命周期)流程,从安全风险管理的视角来避免安全风险。 5 U, U1 N& A5 ^3 B1 C
6 y# D+ s& y5 S- ^4 b0 R! [% m( x# i
SDL从需求阶段、设计阶段、实施阶段、测试阶段和发布响应阶段来引入安全管理。SDL的各个阶段相关内容可参考上图。 # C: p' v1 {" \9 m
5 }' [) w6 o3 T3 ^
原创:security intelligence - q+ h8 x- s( q, V9 w0 \4 W
V% D0 _; d; v' k2 Q3 k K B9 J
|