重磅推荐
【产品特色】

【编辑推荐】
在全世界的所有组织中,敏捷开发正在成为*广泛使用的软件开发方法,但它通常无法和传统的安全管理技术相融合。大部分安全专业技术人员的知识都跟不上敏捷开发的发展。为了将这连个领域打通,本书引入了几个在敏捷开发使用的安全工具和技术。这本书由安全专家和敏捷高手编写,本书一开始就向敏捷实践者介绍了安全原则,同时向安全实践者介绍了敏捷原则。作者还介绍了他们在自己的敏捷安全实践中所遇到的问题,以及他们如何解决这些问题。
【内容简介】
你将在本书中学习到:在软件开发生命周期的每一阶段中加入安全措施。在计划、需求、设计和编码阶段集成安全。在每个发布版本中加入安全测试,并将它作为团队发布工作中的一部分。在敏捷开发或 DevOps 环境中实现合规。通过共鸣、开放、透明、协作构建高效安全的程序。
【作者简介】
Laura Bell,SafeStack创始人和首席顾问。Michael Brunton-Spall,公共数字服务部的技术及运营副主任。Rich Smith,Duo的研发总监。
【目录】
前言 1
第1章 安全概述 9
不仅仅是技术问题 10
不仅仅是极客 11
安全和风险有关 12
威胁因素,以及了解你的敌人 15
安全价值:保护我们的数据、系统和人员 17
常见的安全误区和错误 19
让我们开始 21
第2章 敏捷促进者 22
构建管道 22
自动化测试 23
持续集成 26
基础设施即代码 26
发布管理 28
可视化追踪 29
集中反馈 30
部署过的代码才是*优秀的代码 31
安全、高速运行 31
第3章 迎接敏捷革命的到来 33
敏捷:一座美丽的盆景 33
Scrum,*时髦的敏捷技术 36
极限编程 39
看板 42
精益开发 45
常见敏捷方法 46
什么是 DevOps? 48
敏捷和安全 49
第4章 在现有的敏捷生命周期中工作 51
传统应用的安全模型 51
迭代前仪式 54
迭代前参与 56
迭代后参与 57
设置安全基线 58
那么当你扩大规模的时候呢? 59
建立安全团队 59
关键点 61
第5章 安全和需求 63
在需求中处理安全 63
敏捷需求:讲述故事 64
跟踪和管理故事:backlog 66
处理bug 67
将安全性放入需求 67
安全角色和反角色 74
攻击者故事:戴上黑帽子 76
攻击树 79
基础架构和运维需求 82
重点回顾 85
第6章 敏捷漏洞管理 87
漏洞扫描及修复 87
处理关键漏洞 93
确保软件供应链安全 94
如何以敏捷方式修复漏洞 96
安全Sprints、强化Sprints和黑客日 100
技术安全债务的承担和偿还 101
关键点 103
第7章 敏捷团队的风险 104
安全团队说不 104
理解风险和风险管理 105
风险和威胁 106
风险处置 107
敏捷和DevOps中的风险管理 112
在敏捷和DevOps中处理安全风险 117
重点回顾 119
第8章 理解攻击和评估风险 120
理解攻击:妄想和现实 121
系统的攻击面 129
敏捷威胁建模 132
常见攻击方式 142
要点总结 143
第9章 构建安全和可用的系统 145
反入侵设计 145
安全性与可用性 146
技术控制 146
安全架构 149
复杂性和安全性 152
重点回顾 154
第10章 代码评审安全 155
为什么需要进行代码评审? 155
代码评审的类型 156
结对代码评审 158
你应该何时评审代码? 160
怎样评审代码? 161
谁需要评审代码? 167
自动代码评审 169
代码评审的挑战和局限性 178
采用安全代码评审 181
查看安全功能和控件 186
评审代码的内部威胁 187
关键要点 188
第11章 敏捷安全测试 191
那么敏捷开发中如何进行测试? 191
有bug 的地方,就会被攻破 192
敏捷测试金字塔 194
单元测试和TDD 196
服务级别的测试和BDD工具 199
验收测试 201
功能安全测试和扫描 202
应用程序扫描的问题 206
测试基础设施 208
创建自动化的构建和测试管道 212
敏捷开发中的手动测试 218
如何在敏捷和DevOps中进行安全测试? 220
重点回顾 221
第12章 外部审计,测试和建议 223
为什么我们需要外部审计? 224
缺陷评估 226
渗透测试 227
红队 229
BUG奖励 231
配置审查 238
安全代码审计 238
加密审计 239
选择一个外部的公司 240
使你的钱花的值得 242
关键点 246
第13章 运维和OpSec 247
系统加固:建立安全系统 248
网络即代码 256
监控与入侵检测 257
在运行时捕捉错误 262
运行时防御 264
事件反应:为破坏而准备 266
保护你的构建管道 270
嘘……请保密 277
重点回顾 279
第14章 合规性 281
合规性和安全性 281
风险管理和合规 288
变更的可追溯性 289
数据隐私 290
如何满足合规性并保持敏捷 292
证明和认证 303
关键点 304
第15章 安全文化 306
安全文化的意义 306
搭建安全文化 307
有效安全原则 309
安全外展 320
重点回顾 327
第16章 敏捷安全意味着什么? 328
Laura的故事 328
Jim的故事 331
Michael的故事 335
Rich的故事 339

【前言】
前言
软件正在改变这个世界。开发者成为了新的无冕之王。物联网意味着每个电灯泡中都会有一台计算机存在。这种说法也表明软件开发越来越占据了统治地位,世界上大多数人距离某台计算机不会超过1米,在任何时候我们都生活在计算机辅助类物品或环境的影响下。但随之而来的却是某种危机。
在过去,安全通常是银行业和政府系统才需要真正考虑的事情。但由于计算机无处不在,通过系统滥用的可行性增加了,从而诱发了系统滥用,增加了系统所要面对的风险。敏捷开发技术越来越被大多数组织所快速采用。通过响应式改变以及开发成本的明显降低,它们以一种敏捷的方式提供了理想的、能够不断迭代直到软件大版本被构建出来的标准。
但是,从历史观点来说,安全和敏捷从来不是天生的一对。在前面提到的政府、经济和银行系统中,安全专家正在忙得不可开交,他们正在努力构建、测试和加固这些系统,以应对层出不穷的各种威胁。而且,我们经常可以在技术博客和晚间新闻中看到的*有趣、*刺激的东西,也主要集中在职业黑客团队所做的漏洞研究、Exploit开发和特技攻击上。你可能听过几个*的漏洞,比如心血漏洞(Heartbleed)、阻塞漏洞(Logjam)及破壳漏洞(Shellshock),也可能知道几个能够越狱*iPhone和Android设备的团队。但除了*终出现的那个带有好听的、媒体友好名字的防御措施或方法之外,你还记得任何一个防御者或者建设者的名字吗?安全专家在敏捷开发方面的知识和经验已经落伍了,在我们这个行业中已经出现了一个惊人的鸿沟。同样地,敏捷开发团队拒绝和摆脱了过去的羁绊。没有详细的需求说明、没有系统建模、没有传统的瀑布切换和控制门。
但问题是,敏捷团队将洗澡水和婴儿一起泼出去了。那些有时候既缓慢又不灵活的实践,在过去也曾经证明过是有价值的。它们的存在是有原因的,敏捷团队丢弃了它们,很容易就忽略和丢掉了它们的价值。这意味着敏捷团队是尽可能地不考虑安全问题。有一些敏捷实践让系统更安全,但那通常是一个意外惊喜而不是故意设计。很少有敏捷团队会意识到他们系统面临的威胁;不理解他们正处于风险之中;不跟踪或者不会控制这些风险;对有人会攻击他们的系统缺乏理解。
本书的读者对象我们不知道你是一个敏捷团队的领导者,还是一个想知道更多安全知识的开发者,也可能是一个安全行业的从业者,发现整个开发团队已经不是你曾经认识过的样子,你想学习更多。这本书的目标是针对这三种主要的读者。敏捷开发者你活着、呼吸着,所以敏捷。你从你的Kaizen中知道你的Scrum,在你的反馈循环中进行测试驱动开发。无论你是不是一个Scrum大师,开发者、测试者、敏捷开发讲师、产品的业主,还是客户代理,你都需要理解敏捷开发的实践和价值。本书将帮助你学习什么是安全,存在什么样的威胁,以及安全从业者用于描述所发生的事情的语言。我们会帮助你理解如何建模威胁,度量风险,从理论上构建安全软件,安全地安装软件,以及理解运营中来自于某个在线服务的安全问题。
安全从业者无论你是否是一个风险管理者、一个信息安全专家,还是一个安全运营分析家,你应该理解安全。你可能关心如何使用在线服务,无时不刻不在思考各种威胁、风险以及缓解措施,你甚至发现过新漏洞并利用它们进行过提权。这本书会帮助你理解敏捷团队是如何真正对软件进行开发的,这个地球上的这类团队正在谈论什么,以及他们口中的冲刺和故事是什么。你将学习查看chaos中的模板,以及帮助你和团队进行交流并影响他们。本书将告诉你可以从哪些地方介入或者做出努力,这也是对一个敏捷团队*价值和*能发挥作用的地方。敏捷安全从业者从风险到冲刺,你无一不知。无论你是一个帮助团队做好安全的工具创建者,还是一个负责对团队提建议的顾问,本书都适合你。抛开本书的主要内容,去理解本书作者的意图,也就是正在增长的良好实践。本书将有助于了解在你领域内的其他人,以及我们正在组织中处理这个问题时出现的想法和概念。这会提高、扩展你对相关域的理解,以及为你提供一个继续研究学习的目标。
本书主要内容你可以按从头到尾的顺序来逐章阅读本书。实际上我们也推荐你以这种方式阅读;我们努力编写本书,希望在每一章都包含对所有读者有用的内容,哪怕一个小小的冷幽默或趣闻轶事!但实际上,我们也认为有的章对你来说会比其他章更有用。
大致将本书分成三个部分。
*部分:基础敏捷和安全是非常宽的领域,我们不知道你掌握了什么。尤其当你是来自其中某一个领域时,你可能不知道另一个领域的知识。如果你是敏捷专家,我们建议你先阅读第1章,“安全概述”,以确保你具备基本的安全知识。如果你不是,或者你还刚刚开始接触敏捷开发,那么在我们开始介绍敏捷之前,我们建议你阅读第2章,“敏捷促进者”。这一章介绍了我们认为的基本实践是什么,以及我们将从什么样的基础开始。第3章,“迎接敏捷革命的到来”,介绍敏捷软件开发的历史,以及它的不同实现方式。对于安全专家和没有敏捷开发经验的人来说,这也是他们*感兴趣的部分。
第二部分:敏捷和安全我们建议每个人都开始阅读第4章,“在现有的敏捷生命周期中工作”。在这一章中,试图将我们想到的安全实践和真实的敏捷开发生命周期联系到一起,同时解释说明为什么要将它们联系起来。第5~7章,学习需求和漏洞管理、风险管理,这些更全面的实践将从一个方面支撑起开发中的产品管理和总体方案。第8~13章包括了安全软件开发生命周期的各个组成部分,从评估、代码评审、测试到运行安全。
第三部分:*后组装第14章,介绍合规性,以及它和安全有何关系,如何在敏捷开发或DevOps环境中实现合规。第15章,介绍安全的文化体系。没错,你可以实现本书介绍的所有实践,前面的章节介绍了你能够使这些改变持续的各种工具。然而敏捷开发都是关于人的,有效的安全持续也是这样:安全其实是改变内心的文化,这一章会提供一些我们在真实世界中找到的有效案例。
对于一个公司,要改变它的安全性,它需要安全专家和开发人员相互支持和尊重,他们需要密切合作以构建安全持续。它不仅仅是一堆工具或一系列实践,还需要这个组织的彻底改变。第16章,介绍敏捷安全对不同的人意味着什么,并归纳出要让团队敏捷和安全,我们每个人应该干什么和不应该干什么。
本书约定本书常用到的排版方式约定如下:斜体(Italic)表示新出现的术语、URL、email地址、文件名及扩展名。等宽字体(Constant Width)在代码清单中使用,或者在段落中用于表示程序中的对象,如变量名、函数名、数据库、数据类型,环境变量、语句和关键字。如果在代码行后出现↵字符,表示这一行后面是下一行。加粗的等宽字体(Constant width bold)表示命令或需要用户输入的其他文本。倾斜的等宽字体(Constant Width Italic)表示文本应该由用户自己提供的内容替换,或者根据上下文改变。O’Reilly SafariSafari(过去叫Safari图书在线)是一个针对企业、政府、教育机构和个人的会员制培训和参考平台。成为会员将可以从数据库中查找和浏览数以千计的图书、培训视频、学习路径、交互式教程和组织好的播放列表,这些资料的来源遍及250个出版社,如O’Reilly Media、Harvard Business Review、Prentice Hall Professional、Addison-Wesley Professional、Microsoft Press、Sams、Que、Peachpit Press、Adobe、Focal Press、Cisco Press、John Wiley & Sons、Syngress、Morgan Kaufmann、IBM Redbooks、Packt, Adobe Press、FT Press、Apress、Manning、New Riders、McGraw-Hill、Jones & Bartlett、Course Technology等。更多信息,请访问:http://oreilly.com/safari。
联系我们请把你对本书的意见和疑问发给出版社:美国:O’Reilly Media, Inc.1005 Gravenstein Highway NorthSebastopol, CA 95472中国:北京市西城区西直门南大街2号成铭大厦C座807室(100035)奥莱利技术咨询(北京)有限公司本书有一个专属网页,我们会在上面列出勘误、示例,以及其他附加信息。你可以通过以下地址访问它:http://bit.ly/agile-application-security。如果是评论或者讨论和本书相关的技术问题,那么请发邮件到bookquestions@oreilly.com。关于我们出版社的其他书籍、教程、会议和新闻,请访问我们的网站http://www.oreilly.com。我们的Facebook:http://facebook.com/oreilly。我们的Twitter:http://twitter.com/oreillymedia。我们的YouTube:http://www.youtube.com/oreillymedia。
致谢首先要感谢三位了不起的编辑:Courtney Allen、Virgnia Wilson和Nan Barber。没有你们和其他O’Reilly团队的成员,我们无法完成本书。我们还要感谢技术评审的耐心和真知灼见,分别是:Ben Allen、Geoff Kratz、Pete McBreen、Kelly Shortridge和Nenad Stojanovsk。*后还要感谢我们的朋友和家人,忍受我们再次从事这样一个疯狂的项目。

返回顶部