security in the software development lifecycle · security in the software development lifecycle...
TRANSCRIPT
![Page 1: Security In The Software Development Lifecycle · Security In The Software Development Lifecycle Hala Assal & Sonia Chiasson School of Computer Science, Carleton University Ottawa](https://reader034.vdocuments.mx/reader034/viewer/2022050502/5f94c2acbe6f712f0e202fdd/html5/thumbnails/1.jpg)
Security In The Software Development Lifecycle
Hala Assal & Sonia ChiassonSchool of Computer Science, Carleton University
Ottawa ON, [email protected]
1
![Page 2: Security In The Software Development Lifecycle · Security In The Software Development Lifecycle Hala Assal & Sonia Chiasson School of Computer Science, Carleton University Ottawa](https://reader034.vdocuments.mx/reader034/viewer/2022050502/5f94c2acbe6f712f0e202fdd/html5/thumbnails/2.jpg)
Why?
• Vulnerabilities persist
• Increasing and evolving threats
• Developers are not the enemy
https://www.forbes.com
2
![Page 3: Security In The Software Development Lifecycle · Security In The Software Development Lifecycle Hala Assal & Sonia Chiasson School of Computer Science, Carleton University Ottawa](https://reader034.vdocuments.mx/reader034/viewer/2022050502/5f94c2acbe6f712f0e202fdd/html5/thumbnails/3.jpg)
Related Work• Security tools’ adoption
• E.g., Witschey et al., 2014; Xiao et al., 2014; Xie et al., 2011
• Proposing and improving new tools and methodologies
• E.g., Smith et al., 2018; Nguyen et al., 2017; Xie et al., 2011
• Developers’ abilities and experience
• E.g., Smith et al., 2015; Oliveira et al., 2014; Baca et al., 2009 3
![Page 4: Security In The Software Development Lifecycle · Security In The Software Development Lifecycle Hala Assal & Sonia Chiasson School of Computer Science, Carleton University Ottawa](https://reader034.vdocuments.mx/reader034/viewer/2022050502/5f94c2acbe6f712f0e202fdd/html5/thumbnails/4.jpg)
The overall security processExisting practices compared to best practices
4
![Page 5: Security In The Software Development Lifecycle · Security In The Software Development Lifecycle Hala Assal & Sonia Chiasson School of Computer Science, Carleton University Ottawa](https://reader034.vdocuments.mx/reader034/viewer/2022050502/5f94c2acbe6f712f0e202fdd/html5/thumbnails/5.jpg)
Approach
5
Interview studyExplore existing
practicesAmalgamate best
practices
Compare practicesExplore influential
factors
![Page 6: Security In The Software Development Lifecycle · Security In The Software Development Lifecycle Hala Assal & Sonia Chiasson School of Computer Science, Carleton University Ottawa](https://reader034.vdocuments.mx/reader034/viewer/2022050502/5f94c2acbe6f712f0e202fdd/html5/thumbnails/6.jpg)
Study Design
• Semi-structured interview
• Software engineering + security topics
• ~1hr sessions
• Audio recorded and transcribed
6
![Page 7: Security In The Software Development Lifecycle · Security In The Software Development Lifecycle Hala Assal & Sonia Chiasson School of Computer Science, Carleton University Ottawa](https://reader034.vdocuments.mx/reader034/viewer/2022050502/5f94c2acbe6f712f0e202fdd/html5/thumbnails/7.jpg)
Participants
• 13 professional developers
• Avg. experience = 9.35 years (Md=8)
• 15 teams in 15 different companies
• 7 SMEs and 8 large enterprises
7
![Page 8: Security In The Software Development Lifecycle · Security In The Software Development Lifecycle Hala Assal & Sonia Chiasson School of Computer Science, Carleton University Ottawa](https://reader034.vdocuments.mx/reader034/viewer/2022050502/5f94c2acbe6f712f0e202fdd/html5/thumbnails/8.jpg)
Analysis Methodology
• Qualitative Content Analysis (Elo & Kyngäs, 2008)
• Deductive and inductive approaches
• Analysis Matrix of development activities
• 264 unique excerpts
8
Selectingtheunitofanalysis
Makingsenseofthedataandobtainasenseofwhole
Opencoding
Codingsheets
Grouping
Categorization
Abstraction
Developingstructuredanalysis
matrix
Datacodingaccordingtothecategories
Hypothesistestingandcomparisontoearlierstudies
Developinganalysismatrix
Datagatheringbycontent
Model,conceptualsystemconceptualmaporcategories
Deductive approach Inductive approach
![Page 9: Security In The Software Development Lifecycle · Security In The Software Development Lifecycle Hala Assal & Sonia Chiasson School of Computer Science, Carleton University Ottawa](https://reader034.vdocuments.mx/reader034/viewer/2022050502/5f94c2acbe6f712f0e202fdd/html5/thumbnails/9.jpg)
Analysis Methodology
• Qualitative Content Analysis (Elo & Kyngäs, 2008)
• Deductive and inductive approaches
• Analysis Matrix of development activities
• 264 unique excerpts
9
Selectingtheunitofanalysis
Makingsenseofthedataandobtainasenseofwhole
Opencoding
Codingsheets
Grouping
Categorization
Abstraction
Developingstructuredanalysis
matrix
Datacodingaccordingtothecategories
Hypothesistestingandcomparisontoearlierstudies
Developinganalysismatrix
Datagatheringbycontent
Model,conceptualsystemconceptualmaporcategories
Deductive approach Inductive approach
![Page 10: Security In The Software Development Lifecycle · Security In The Software Development Lifecycle Hala Assal & Sonia Chiasson School of Computer Science, Carleton University Ottawa](https://reader034.vdocuments.mx/reader034/viewer/2022050502/5f94c2acbe6f712f0e202fdd/html5/thumbnails/10.jpg)
Analysis Methodology
• Qualitative Content Analysis (Elo & Kyngäs, 2008)
• Deductive and inductive approaches
• Analysis Matrix of development activities
• 264 unique excerpts
10
Selectingtheunitofanalysis
Makingsenseofthedataandobtainasenseofwhole
Opencoding
Codingsheets
Grouping
Categorization
Abstraction
Developingstructuredanalysis
matrix
Datacodingaccordingtothecategories
Hypothesistestingandcomparisontoearlierstudies
Developinganalysismatrix
Datagatheringbycontent
Model,conceptualsystemconceptualmaporcategories
Deductive approach Inductive approach
![Page 11: Security In The Software Development Lifecycle · Security In The Software Development Lifecycle Hala Assal & Sonia Chiasson School of Computer Science, Carleton University Ottawa](https://reader034.vdocuments.mx/reader034/viewer/2022050502/5f94c2acbe6f712f0e202fdd/html5/thumbnails/11.jpg)
Analysis Methodology
• Qualitative Content Analysis (Elo & Kyngäs, 2008)
• Deductive and inductive approaches
• Analysis Matrix of development activities
• 264 unique excerpts
11
Selectingtheunitofanalysis
Makingsenseofthedataandobtainasenseofwhole
Opencoding
Codingsheets
Grouping
Categorization
Abstraction
Developingstructuredanalysis
matrix
Datacodingaccordingtothecategories
Hypothesistestingandcomparisontoearlierstudies
Developinganalysismatrix
Datagatheringbycontent
Model,conceptualsystemconceptualmaporcategories
Deductive approach Inductive approach
![Page 12: Security In The Software Development Lifecycle · Security In The Software Development Lifecycle Hala Assal & Sonia Chiasson School of Computer Science, Carleton University Ottawa](https://reader034.vdocuments.mx/reader034/viewer/2022050502/5f94c2acbe6f712f0e202fdd/html5/thumbnails/12.jpg)
Analysis Methodology
• Qualitative Content Analysis (Elo & Kyngäs, 2008)
• Deductive and inductive approaches
• Analysis Matrix of development activities
• 264 unique excerpts
12
Selectingtheunitofanalysis
Makingsenseofthedataandobtainasenseofwhole
Opencoding
Codingsheets
Grouping
Categorization
Abstraction
Developingstructuredanalysis
matrix
Datacodingaccordingtothecategories
Hypothesistestingandcomparisontoearlierstudies
Developinganalysismatrix
Datagatheringbycontent
Model,conceptualsystemconceptualmaporcategories
Deductive approach Inductive approach
![Page 13: Security In The Software Development Lifecycle · Security In The Software Development Lifecycle Hala Assal & Sonia Chiasson School of Computer Science, Carleton University Ottawa](https://reader034.vdocuments.mx/reader034/viewer/2022050502/5f94c2acbe6f712f0e202fdd/html5/thumbnails/13.jpg)
Security In Practice
13
![Page 14: Security In The Software Development Lifecycle · Security In The Software Development Lifecycle Hala Assal & Sonia Chiasson School of Computer Science, Carleton University Ottawa](https://reader034.vdocuments.mx/reader034/viewer/2022050502/5f94c2acbe6f712f0e202fdd/html5/thumbnails/14.jpg)
The Security Adopters & The Security Inattentive
SecurityAdopters SecurityInattentive
:secure, :somewhatsecure, :notsecure, :notperformed, :nodata 14
![Page 15: Security In The Software Development Lifecycle · Security In The Software Development Lifecycle Hala Assal & Sonia Chiasson School of Computer Science, Carleton University Ottawa](https://reader034.vdocuments.mx/reader034/viewer/2022050502/5f94c2acbe6f712f0e202fdd/html5/thumbnails/15.jpg)
Table 2: Summary of themes emerging from the security adopters and the security inattentive, and common themes betweenthe two groups. Although common themes exist, driving factors for these themes may di↵er. See Section 4.2 for more details.
Security Adopters Themes Common Themes Security Inattentive Themes
Design
· Security design is very important · Security is not considered in the designstage
· Security consideration in the design stage is adhoc
Implementation
· Security is a priority during implementa-tion
· Developers’ awareness of security is ex-pected when implementing
· Security is not a priority during implementation· Developers take security for granted· Developers misuse frameworks· Developers lack security knowledge· Developers perceive their security knowledge inaccurately· Vulnerability discovery can motivate security
Developer Testing
· Developers test for security fortuitously· Security is a priority during developer testing
· Developers do not test for security · Developers’ security testing is feature-driven
Code Analysis
· Security is a priority during code analysis · Security is a secondary objective during code analysis· Developers rarely perform code analysis, never for security· Developers vary in awareness of analysis tools
Code Review
· Code review is a formal process that includes security· Preliminary code review is done as a checkpoint be-fore the formal review
· Security is not considered during code review· Security consideration in code review is minimal
Post-development Testing
· Security is a priority during post-development testing· Post-development testing is used to discover securityvulnerabilities, or for final verification
· Testers have the final approval
· Security is not considered in post-development testing· Post-development testing plans include a security dimension· Post-development security testing is feature-driven· Post-development security testing is adhoc· Post-development security testing is externally-driven
and developers, whereas the Testing Guide [4] focuses onbest practices for testing and evaluating security activities.
Others. Additional resources for security best practices in-clude: NASA’s Software Assurance Guidebook [39], NIST’sSpecial Publication 800-64 [32], US-CERT’s Top 10 SecureCoding Practices [47], as well as various articles emphasizingthe importance of secure development [7, 36,37,57].
5.2 Security Best PracticesAvailable resources for security best practices vary in theirorganization and their presentation style, e.g., they vary intechnical details. Practitioners may find di�culty decidingon best practices to follow and establishing processes withintheir organizations [38,42,54]. To help frame security prac-tices we identified, we collected recommendations from thesources discussed in Section 5.1 to compose a concise set ofbest practices. This resulted in an initial set of 57 unor-ganized recommendations varying in format and technicaldetails. We then grouped related recommendations, orga-nized them in high-level themes, and iterated this process tofinally produce the following 12 best practices. Other amal-gamations may be possible, but we found this list helpful tointerpret our study results. The list could be of independentinterest to complementary research in this area.
B1 Identify security requirements. Identify security re-quirements for your application during the initial planningstages. The security of the application throughout its dif-ferent stages should be evaluated based on its compliancewith security requirements.B2 Design for security. Aim for simple designs because
the likelihood of implementation errors increases with de-sign complexity. Architect and design your software to im-plement security policies and comply with security princi-ples such as: secure defaults, default deny, fail safe, andthe principle of least privilege.B3 Perform threat modelling. Use threat modelling toanalyze potential threats to your application. The resultof threat modelling should inform security practices in thedi↵erent SDLC stages, e.g., for creating test plans.B4 Perform secure implementation. Adopt secure cod-ing standards for the programming language you use, e.g.,validate input and sanitize data sent to other systems, andavoid using unsafe or deprecated functions.B5 Use approved tools and analyze third-party tools’
security. Only use approved tools, APIs, and frameworksor those evaluated for security and e↵ectiveness.B6 Include security in testing. Integrate security testingin functional test plans to reduce redundancy.B7 Perform code analysis. Leverage automated toolssuch as SATs to detect vulnerabilities like bu↵er overflowsand improper user input validation.B8 Perform code review for security. Include securityin code reviews and look for common programming errorsthat can lead to security vulnerabilities.B9 Perform post-development testing. Identify secu-rity issues further by using a combination of methods, e.g.,dynamic analysis, penetration testing, or hiring externalsecurity reviewers to bring in a new perspective.
B10 Apply defense in depth. Build security in all stagesof the SDLC, so that if a vulnerability is missed in onestage, there is a chance to eliminate it through practicesimplemented in the remaining stages.
15
![Page 16: Security In The Software Development Lifecycle · Security In The Software Development Lifecycle Hala Assal & Sonia Chiasson School of Computer Science, Carleton University Ottawa](https://reader034.vdocuments.mx/reader034/viewer/2022050502/5f94c2acbe6f712f0e202fdd/html5/thumbnails/16.jpg)
Table 2: Summary of themes emerging from the security adopters and the security inattentive, and common themes betweenthe two groups. Although common themes exist, driving factors for these themes may di↵er. See Section 4.2 for more details.
Security Adopters Themes Common Themes Security Inattentive Themes
Design
· Security design is very important · Security is not considered in the designstage
· Security consideration in the design stage is adhoc
Implementation
· Security is a priority during implementa-tion
· Developers’ awareness of security is ex-pected when implementing
· Security is not a priority during implementation· Developers take security for granted· Developers misuse frameworks· Developers lack security knowledge· Developers perceive their security knowledge inaccurately· Vulnerability discovery can motivate security
Developer Testing
· Developers test for security fortuitously· Security is a priority during developer testing
· Developers do not test for security · Developers’ security testing is feature-driven
Code Analysis
· Security is a priority during code analysis · Security is a secondary objective during code analysis· Developers rarely perform code analysis, never for security· Developers vary in awareness of analysis tools
Code Review
· Code review is a formal process that includes security· Preliminary code review is done as a checkpoint be-fore the formal review
· Security is not considered during code review· Security consideration in code review is minimal
Post-development Testing
· Security is a priority during post-development testing· Post-development testing is used to discover securityvulnerabilities, or for final verification
· Testers have the final approval
· Security is not considered in post-development testing· Post-development testing plans include a security dimension· Post-development security testing is feature-driven· Post-development security testing is adhoc· Post-development security testing is externally-driven
and developers, whereas the Testing Guide [4] focuses onbest practices for testing and evaluating security activities.
Others. Additional resources for security best practices in-clude: NASA’s Software Assurance Guidebook [39], NIST’sSpecial Publication 800-64 [32], US-CERT’s Top 10 SecureCoding Practices [47], as well as various articles emphasizingthe importance of secure development [7, 36,37,57].
5.2 Security Best PracticesAvailable resources for security best practices vary in theirorganization and their presentation style, e.g., they vary intechnical details. Practitioners may find di�culty decidingon best practices to follow and establishing processes withintheir organizations [38,42,54]. To help frame security prac-tices we identified, we collected recommendations from thesources discussed in Section 5.1 to compose a concise set ofbest practices. This resulted in an initial set of 57 unor-ganized recommendations varying in format and technicaldetails. We then grouped related recommendations, orga-nized them in high-level themes, and iterated this process tofinally produce the following 12 best practices. Other amal-gamations may be possible, but we found this list helpful tointerpret our study results. The list could be of independentinterest to complementary research in this area.
B1 Identify security requirements. Identify security re-quirements for your application during the initial planningstages. The security of the application throughout its dif-ferent stages should be evaluated based on its compliancewith security requirements.B2 Design for security. Aim for simple designs because
the likelihood of implementation errors increases with de-sign complexity. Architect and design your software to im-plement security policies and comply with security princi-ples such as: secure defaults, default deny, fail safe, andthe principle of least privilege.B3 Perform threat modelling. Use threat modelling toanalyze potential threats to your application. The resultof threat modelling should inform security practices in thedi↵erent SDLC stages, e.g., for creating test plans.B4 Perform secure implementation. Adopt secure cod-ing standards for the programming language you use, e.g.,validate input and sanitize data sent to other systems, andavoid using unsafe or deprecated functions.B5 Use approved tools and analyze third-party tools’
security. Only use approved tools, APIs, and frameworksor those evaluated for security and e↵ectiveness.B6 Include security in testing. Integrate security testingin functional test plans to reduce redundancy.B7 Perform code analysis. Leverage automated toolssuch as SATs to detect vulnerabilities like bu↵er overflowsand improper user input validation.B8 Perform code review for security. Include securityin code reviews and look for common programming errorsthat can lead to security vulnerabilities.B9 Perform post-development testing. Identify secu-rity issues further by using a combination of methods, e.g.,dynamic analysis, penetration testing, or hiring externalsecurity reviewers to bring in a new perspective.
B10 Apply defense in depth. Build security in all stagesof the SDLC, so that if a vulnerability is missed in onestage, there is a chance to eliminate it through practicesimplemented in the remaining stages.
16
Security Adopters
Security Inattentive
![Page 17: Security In The Software Development Lifecycle · Security In The Software Development Lifecycle Hala Assal & Sonia Chiasson School of Computer Science, Carleton University Ottawa](https://reader034.vdocuments.mx/reader034/viewer/2022050502/5f94c2acbe6f712f0e202fdd/html5/thumbnails/17.jpg)
Table 2: Summary of themes emerging from the security adopters and the security inattentive, and common themes betweenthe two groups. Although common themes exist, driving factors for these themes may di↵er. See Section 4.2 for more details.
Security Adopters Themes Common Themes Security Inattentive Themes
Design
· Security design is very important · Security is not considered in the designstage
· Security consideration in the design stage is adhoc
Implementation
· Security is a priority during implementa-tion
· Developers’ awareness of security is ex-pected when implementing
· Security is not a priority during implementation· Developers take security for granted· Developers misuse frameworks· Developers lack security knowledge· Developers perceive their security knowledge inaccurately· Vulnerability discovery can motivate security
Developer Testing
· Developers test for security fortuitously· Security is a priority during developer testing
· Developers do not test for security · Developers’ security testing is feature-driven
Code Analysis
· Security is a priority during code analysis · Security is a secondary objective during code analysis· Developers rarely perform code analysis, never for security· Developers vary in awareness of analysis tools
Code Review
· Code review is a formal process that includes security· Preliminary code review is done as a checkpoint be-fore the formal review
· Security is not considered during code review· Security consideration in code review is minimal
Post-development Testing
· Security is a priority during post-development testing· Post-development testing is used to discover securityvulnerabilities, or for final verification
· Testers have the final approval
· Security is not considered in post-development testing· Post-development testing plans include a security dimension· Post-development security testing is feature-driven· Post-development security testing is adhoc· Post-development security testing is externally-driven
and developers, whereas the Testing Guide [4] focuses onbest practices for testing and evaluating security activities.
Others. Additional resources for security best practices in-clude: NASA’s Software Assurance Guidebook [39], NIST’sSpecial Publication 800-64 [32], US-CERT’s Top 10 SecureCoding Practices [47], as well as various articles emphasizingthe importance of secure development [7, 36,37,57].
5.2 Security Best PracticesAvailable resources for security best practices vary in theirorganization and their presentation style, e.g., they vary intechnical details. Practitioners may find di�culty decidingon best practices to follow and establishing processes withintheir organizations [38,42,54]. To help frame security prac-tices we identified, we collected recommendations from thesources discussed in Section 5.1 to compose a concise set ofbest practices. This resulted in an initial set of 57 unor-ganized recommendations varying in format and technicaldetails. We then grouped related recommendations, orga-nized them in high-level themes, and iterated this process tofinally produce the following 12 best practices. Other amal-gamations may be possible, but we found this list helpful tointerpret our study results. The list could be of independentinterest to complementary research in this area.
B1 Identify security requirements. Identify security re-quirements for your application during the initial planningstages. The security of the application throughout its dif-ferent stages should be evaluated based on its compliancewith security requirements.B2 Design for security. Aim for simple designs because
the likelihood of implementation errors increases with de-sign complexity. Architect and design your software to im-plement security policies and comply with security princi-ples such as: secure defaults, default deny, fail safe, andthe principle of least privilege.B3 Perform threat modelling. Use threat modelling toanalyze potential threats to your application. The resultof threat modelling should inform security practices in thedi↵erent SDLC stages, e.g., for creating test plans.B4 Perform secure implementation. Adopt secure cod-ing standards for the programming language you use, e.g.,validate input and sanitize data sent to other systems, andavoid using unsafe or deprecated functions.B5 Use approved tools and analyze third-party tools’
security. Only use approved tools, APIs, and frameworksor those evaluated for security and e↵ectiveness.B6 Include security in testing. Integrate security testingin functional test plans to reduce redundancy.B7 Perform code analysis. Leverage automated toolssuch as SATs to detect vulnerabilities like bu↵er overflowsand improper user input validation.B8 Perform code review for security. Include securityin code reviews and look for common programming errorsthat can lead to security vulnerabilities.B9 Perform post-development testing. Identify secu-rity issues further by using a combination of methods, e.g.,dynamic analysis, penetration testing, or hiring externalsecurity reviewers to bring in a new perspective.
B10 Apply defense in depth. Build security in all stagesof the SDLC, so that if a vulnerability is missed in onestage, there is a chance to eliminate it through practicesimplemented in the remaining stages.
17
Common
![Page 18: Security In The Software Development Lifecycle · Security In The Software Development Lifecycle Hala Assal & Sonia Chiasson School of Computer Science, Carleton University Ottawa](https://reader034.vdocuments.mx/reader034/viewer/2022050502/5f94c2acbe6f712f0e202fdd/html5/thumbnails/18.jpg)
Table 2: Summary of themes emerging from the security adopters and the security inattentive, and common themes betweenthe two groups. Although common themes exist, driving factors for these themes may di↵er. See Section 4.2 for more details.
Security Adopters Themes Common Themes Security Inattentive Themes
Design
· Security design is very important · Security is not considered in the designstage
· Security consideration in the design stage is adhoc
Implementation
· Security is a priority during implementa-tion
· Developers’ awareness of security is ex-pected when implementing
· Security is not a priority during implementation· Developers take security for granted· Developers misuse frameworks· Developers lack security knowledge· Developers perceive their security knowledge inaccurately· Vulnerability discovery can motivate security
Developer Testing
· Developers test for security fortuitously· Security is a priority during developer testing
· Developers do not test for security · Developers’ security testing is feature-driven
Code Analysis
· Security is a priority during code analysis · Security is a secondary objective during code analysis· Developers rarely perform code analysis, never for security· Developers vary in awareness of analysis tools
Code Review
· Code review is a formal process that includes security· Preliminary code review is done as a checkpoint be-fore the formal review
· Security is not considered during code review· Security consideration in code review is minimal
Post-development Testing
· Security is a priority during post-development testing· Post-development testing is used to discover securityvulnerabilities, or for final verification
· Testers have the final approval
· Security is not considered in post-development testing· Post-development testing plans include a security dimension· Post-development security testing is feature-driven· Post-development security testing is adhoc· Post-development security testing is externally-driven
and developers, whereas the Testing Guide [4] focuses onbest practices for testing and evaluating security activities.
Others. Additional resources for security best practices in-clude: NASA’s Software Assurance Guidebook [39], NIST’sSpecial Publication 800-64 [32], US-CERT’s Top 10 SecureCoding Practices [47], as well as various articles emphasizingthe importance of secure development [7, 36,37,57].
5.2 Security Best PracticesAvailable resources for security best practices vary in theirorganization and their presentation style, e.g., they vary intechnical details. Practitioners may find di�culty decidingon best practices to follow and establishing processes withintheir organizations [38,42,54]. To help frame security prac-tices we identified, we collected recommendations from thesources discussed in Section 5.1 to compose a concise set ofbest practices. This resulted in an initial set of 57 unor-ganized recommendations varying in format and technicaldetails. We then grouped related recommendations, orga-nized them in high-level themes, and iterated this process tofinally produce the following 12 best practices. Other amal-gamations may be possible, but we found this list helpful tointerpret our study results. The list could be of independentinterest to complementary research in this area.
B1 Identify security requirements. Identify security re-quirements for your application during the initial planningstages. The security of the application throughout its dif-ferent stages should be evaluated based on its compliancewith security requirements.B2 Design for security. Aim for simple designs because
the likelihood of implementation errors increases with de-sign complexity. Architect and design your software to im-plement security policies and comply with security princi-ples such as: secure defaults, default deny, fail safe, andthe principle of least privilege.B3 Perform threat modelling. Use threat modelling toanalyze potential threats to your application. The resultof threat modelling should inform security practices in thedi↵erent SDLC stages, e.g., for creating test plans.B4 Perform secure implementation. Adopt secure cod-ing standards for the programming language you use, e.g.,validate input and sanitize data sent to other systems, andavoid using unsafe or deprecated functions.B5 Use approved tools and analyze third-party tools’
security. Only use approved tools, APIs, and frameworksor those evaluated for security and e↵ectiveness.B6 Include security in testing. Integrate security testingin functional test plans to reduce redundancy.B7 Perform code analysis. Leverage automated toolssuch as SATs to detect vulnerabilities like bu↵er overflowsand improper user input validation.B8 Perform code review for security. Include securityin code reviews and look for common programming errorsthat can lead to security vulnerabilities.B9 Perform post-development testing. Identify secu-rity issues further by using a combination of methods, e.g.,dynamic analysis, penetration testing, or hiring externalsecurity reviewers to bring in a new perspective.
B10 Apply defense in depth. Build security in all stagesof the SDLC, so that if a vulnerability is missed in onestage, there is a chance to eliminate it through practicesimplemented in the remaining stages.
18
![Page 19: Security In The Software Development Lifecycle · Security In The Software Development Lifecycle Hala Assal & Sonia Chiasson School of Computer Science, Carleton University Ottawa](https://reader034.vdocuments.mx/reader034/viewer/2022050502/5f94c2acbe6f712f0e202fdd/html5/thumbnails/19.jpg)
Security Adopters Themes Common Themes Security Inattentive Themes
Design
· Security design is very important · Security is not considered in the designstage
· Security consideration in the design stage is adhoc
Implementation
· Security is a priority during implementa-tion
· Developers’ awareness of security is ex-pected when implementing
· Security is not a priority during implementation· Developers take security for granted· Developers misuse frameworks· Developers lack security knowledge· Developers perceive their security knowledge inaccurately· Vulnerability discovery can motivate security
Developer Testing
· Developers test for security fortuitously· Security is a priority during developer testing
· Developers do not test for security · Developers’ security testing is feature-driven
Code Analysis
· Security is a priority during code analysis · Security is a secondary objective during code analysis· Developers rarely perform code analysis, never for security· Developers vary in awareness of analysis tools
Code Review
· Code review is a formal process that includes security· Preliminary code review is done as a checkpoint be-fore the formal review
· Security is not considered during code review· Security consideration in code review is minimal
Post-development Testing
· Security is a priority during post-development testing· Post-development testing is used to discover securityvulnerabilities, or for final verification
· Testers have the final approval
· Security is not considered in post-development testing· Post-development testing plans include a security dimension· Post-development security testing is feature-driven· Post-development security testing is adhoc· Post-development security testing is externally-driven
19
Security is a priority during post-development Security is not considered in post-development
![Page 20: Security In The Software Development Lifecycle · Security In The Software Development Lifecycle Hala Assal & Sonia Chiasson School of Computer Science, Carleton University Ottawa](https://reader034.vdocuments.mx/reader034/viewer/2022050502/5f94c2acbe6f712f0e202fdd/html5/thumbnails/20.jpg)
Table 2: Summary of themes emerging from the security adopters and the security inattentive, and common themes betweenthe two groups. Although common themes exist, driving factors for these themes may di↵er. See Section 4.2 for more details.
Security Adopters Themes Common Themes Security Inattentive Themes
Design
· Security design is very important · Security is not considered in the designstage
· Security consideration in the design stage is adhoc
Implementation
· Security is a priority during implementa-tion
· Developers’ awareness of security is ex-pected when implementing
· Security is not a priority during implementation· Developers take security for granted· Developers misuse frameworks· Developers lack security knowledge· Developers perceive their security knowledge inaccurately· Vulnerability discovery can motivate security
Developer Testing
· Developers test for security fortuitously· Security is a priority during developer testing
· Developers do not test for security · Developers’ security testing is feature-driven
Code Analysis
· Security is a priority during code analysis · Security is a secondary objective during code analysis· Developers rarely perform code analysis, never for security· Developers vary in awareness of analysis tools
Code Review
· Code review is a formal process that includes security· Preliminary code review is done as a checkpoint be-fore the formal review
· Security is not considered during code review· Security consideration in code review is minimal
Post-development Testing
· Security is a priority during post-development testing· Post-development testing is used to discover securityvulnerabilities, or for final verification
· Testers have the final approval
· Security is not considered in post-development testing· Post-development testing plans include a security dimension· Post-development security testing is feature-driven· Post-development security testing is adhoc· Post-development security testing is externally-driven
and developers, whereas the Testing Guide [4] focuses onbest practices for testing and evaluating security activities.
Others. Additional resources for security best practices in-clude: NASA’s Software Assurance Guidebook [39], NIST’sSpecial Publication 800-64 [32], US-CERT’s Top 10 SecureCoding Practices [47], as well as various articles emphasizingthe importance of secure development [7, 36,37,57].
5.2 Security Best PracticesAvailable resources for security best practices vary in theirorganization and their presentation style, e.g., they vary intechnical details. Practitioners may find di�culty decidingon best practices to follow and establishing processes withintheir organizations [38,42,54]. To help frame security prac-tices we identified, we collected recommendations from thesources discussed in Section 5.1 to compose a concise set ofbest practices. This resulted in an initial set of 57 unor-ganized recommendations varying in format and technicaldetails. We then grouped related recommendations, orga-nized them in high-level themes, and iterated this process tofinally produce the following 12 best practices. Other amal-gamations may be possible, but we found this list helpful tointerpret our study results. The list could be of independentinterest to complementary research in this area.
B1 Identify security requirements. Identify security re-quirements for your application during the initial planningstages. The security of the application throughout its dif-ferent stages should be evaluated based on its compliancewith security requirements.B2 Design for security. Aim for simple designs because
the likelihood of implementation errors increases with de-sign complexity. Architect and design your software to im-plement security policies and comply with security princi-ples such as: secure defaults, default deny, fail safe, andthe principle of least privilege.B3 Perform threat modelling. Use threat modelling toanalyze potential threats to your application. The resultof threat modelling should inform security practices in thedi↵erent SDLC stages, e.g., for creating test plans.B4 Perform secure implementation. Adopt secure cod-ing standards for the programming language you use, e.g.,validate input and sanitize data sent to other systems, andavoid using unsafe or deprecated functions.B5 Use approved tools and analyze third-party tools’
security. Only use approved tools, APIs, and frameworksor those evaluated for security and e↵ectiveness.B6 Include security in testing. Integrate security testingin functional test plans to reduce redundancy.B7 Perform code analysis. Leverage automated toolssuch as SATs to detect vulnerabilities like bu↵er overflowsand improper user input validation.B8 Perform code review for security. Include securityin code reviews and look for common programming errorsthat can lead to security vulnerabilities.B9 Perform post-development testing. Identify secu-rity issues further by using a combination of methods, e.g.,dynamic analysis, penetration testing, or hiring externalsecurity reviewers to bring in a new perspective.
B10 Apply defense in depth. Build security in all stagesof the SDLC, so that if a vulnerability is missed in onestage, there is a chance to eliminate it through practicesimplemented in the remaining stages.
20
![Page 21: Security In The Software Development Lifecycle · Security In The Software Development Lifecycle Hala Assal & Sonia Chiasson School of Computer Science, Carleton University Ottawa](https://reader034.vdocuments.mx/reader034/viewer/2022050502/5f94c2acbe6f712f0e202fdd/html5/thumbnails/21.jpg)
–Adopters theme: Security design is very important
“When we go to do a further security analysis, we have a lot more context in terms of what we’re
thinking, and people aren’t running around sort of defending threats that aren’t there. ”
21
![Page 22: Security In The Software Development Lifecycle · Security In The Software Development Lifecycle Hala Assal & Sonia Chiasson School of Computer Science, Carleton University Ottawa](https://reader034.vdocuments.mx/reader034/viewer/2022050502/5f94c2acbe6f712f0e202fdd/html5/thumbnails/22.jpg)
– Inattentive theme: Developer testing is feature-driven
“Security testing [pause] I would say less than 5%. Because we’re doing embedded systems, so security
[is] pretty low in this kind of work.”
22
![Page 23: Security In The Software Development Lifecycle · Security In The Software Development Lifecycle Hala Assal & Sonia Chiasson School of Computer Science, Carleton University Ottawa](https://reader034.vdocuments.mx/reader034/viewer/2022050502/5f94c2acbe6f712f0e202fdd/html5/thumbnails/23.jpg)
Digging Deeper…
23
![Page 24: Security In The Software Development Lifecycle · Security In The Software Development Lifecycle Hala Assal & Sonia Chiasson School of Computer Science, Carleton University Ottawa](https://reader034.vdocuments.mx/reader034/viewer/2022050502/5f94c2acbe6f712f0e202fdd/html5/thumbnails/24.jpg)
• Division of labour• Resource availability• Security knowledge
• Company culture• External pressure• Experiencing a security incident
Factors Affecting Security Practices
24
![Page 25: Security In The Software Development Lifecycle · Security In The Software Development Lifecycle Hala Assal & Sonia Chiasson School of Computer Science, Carleton University Ottawa](https://reader034.vdocuments.mx/reader034/viewer/2022050502/5f94c2acbe6f712f0e202fdd/html5/thumbnails/25.jpg)
Factors Affecting Security Practices• Division of labour• Resource availability• Security knowledge
• Company culture• External pressure• Experiencing a security incident
25
![Page 26: Security In The Software Development Lifecycle · Security In The Software Development Lifecycle Hala Assal & Sonia Chiasson School of Computer Science, Carleton University Ottawa](https://reader034.vdocuments.mx/reader034/viewer/2022050502/5f94c2acbe6f712f0e202fdd/html5/thumbnails/26.jpg)
• Division of labour• Resource availability• Security knowledge
• Company culture• External pressure• Experiencing a security incident
Factors Affecting Security Practices
26
“Probably in the two years that I’ve been working, I never got feedback [on] the security of my code [...]
[Developers reviewing code] don’t pay attention to the security aspect and
they can’t basically make a comment about the security of your code.”
![Page 27: Security In The Software Development Lifecycle · Security In The Software Development Lifecycle Hala Assal & Sonia Chiasson School of Computer Science, Carleton University Ottawa](https://reader034.vdocuments.mx/reader034/viewer/2022050502/5f94c2acbe6f712f0e202fdd/html5/thumbnails/27.jpg)
Factors Affecting Security Practices• Division of labour• Resource availability• Security knowledge
• Company culture• External pressure• Experiencing a security incident
27
![Page 28: Security In The Software Development Lifecycle · Security In The Software Development Lifecycle Hala Assal & Sonia Chiasson School of Computer Science, Carleton University Ottawa](https://reader034.vdocuments.mx/reader034/viewer/2022050502/5f94c2acbe6f712f0e202fdd/html5/thumbnails/28.jpg)
Factors Affecting Security Practices• Division of labour• Resource availability• Security knowledge
• Company culture• External pressure• Experiencing a security incident
28
“No one had really been thinking about looking at the product from security
stand-point and so the new tester we had hired, he really went at it from ‘how can I really break this thing?’ [..] and found quite
a few problems with the product that way.”
![Page 29: Security In The Software Development Lifecycle · Security In The Software Development Lifecycle Hala Assal & Sonia Chiasson School of Computer Science, Carleton University Ottawa](https://reader034.vdocuments.mx/reader034/viewer/2022050502/5f94c2acbe6f712f0e202fdd/html5/thumbnails/29.jpg)
Now What?
29
![Page 30: Security In The Software Development Lifecycle · Security In The Software Development Lifecycle Hala Assal & Sonia Chiasson School of Computer Science, Carleton University Ottawa](https://reader034.vdocuments.mx/reader034/viewer/2022050502/5f94c2acbe6f712f0e202fdd/html5/thumbnails/30.jpg)
Now What?
• Rethink best practices
• Focus on building a security company culture
30
![Page 31: Security In The Software Development Lifecycle · Security In The Software Development Lifecycle Hala Assal & Sonia Chiasson School of Computer Science, Carleton University Ottawa](https://reader034.vdocuments.mx/reader034/viewer/2022050502/5f94c2acbe6f712f0e202fdd/html5/thumbnails/31.jpg)
“To be honest, I don’t think anybody cares about [security]. I’ve never heard or seen people talk
about security at work [...] I did ask about this to my managers, but they just said ‘well, that’s how the
company is. Security is not something we focus on right now.’”
–Factor: Company culture
31