homepage
Open menu
Go one level top
  • Train and Certify
    Train and Certify

    Immediately apply the skills and techniques learned in SANS courses, ranges, and summits

    • Overview
    • Courses
      • Overview
      • Full Course List
      • By Focus Areas
        • Cloud Security
        • Cyber Defense
        • Cybersecurity and IT Essentials
        • DFIR
        • Industrial Control Systems
        • Offensive Operations
        • Management, Legal, and Audit
      • By Skill Levels
        • New to Cyber
        • Essentials
        • Advanced
        • Expert
      • Training Formats
        • OnDemand
        • In-Person
        • Live Online
      • Course Demos
    • Training Roadmaps
      • Skills Roadmap
      • Focus Area Job Roles
        • Cyber Defence Job Roles
        • Offensive Operations Job Roles
        • DFIR Job Roles
        • Cloud Job Roles
        • ICS Job Roles
        • Leadership Job Roles
      • NICE Framework
        • Security Provisionals
        • Operate and Maintain
        • Oversee and Govern
        • Protect and Defend
        • Analyze
        • Collect and Operate
        • Investigate
        • Industrial Control Systems
    • GIAC Certifications
    • Training Events & Summits
      • Events Overview
      • Event Locations
        • Asia
        • Australia & New Zealand
        • Latin America
        • Mainland Europe
        • Middle East & Africa
        • Scandinavia
        • United Kingdom & Ireland
        • United States & Canada
      • Summits
    • OnDemand
    • Get Started in Cyber
      • Overview
      • Degree and Certificate Programs
      • Scholarships
    • Cyber Ranges
  • Manage Your Team
    Manage Your Team

    Build a world-class cyber team with our workforce development programs

    • Overview
    • Why Work with SANS
    • Group Purchasing
    • Build Your Team
      • Team Development
      • Assessments
      • Private Training
      • Hire Cyber Professionals
      • By Industry
        • Health Care
        • Industrial Control Systems Security
        • Military
    • Leadership Training
  • Security Awareness
    Security Awareness

    Increase your staff’s cyber awareness, help them change their behaviors, and reduce your organizational risk

    • Overview
    • Products & Services
      • Security Awareness Training
        • EndUser Training
        • Phishing Platform
      • Specialized
        • Developer Training
        • ICS Engineer Training
        • NERC CIP Training
        • IT Administrator
      • Risk Assessments
        • Knowledge Assessment
        • Culture Assessment
        • Behavioral Risk Assessment
    • OUCH! Newsletter
    • Career Development
      • Overview
      • Training & Courses
      • Professional Credential
    • Blog
    • Partners
    • Reports & Case Studies
  • Resources
    Resources

    Enhance your skills with access to thousands of free resources, 150+ instructor-developed tools, and the latest cybersecurity news and analysis

    • Overview
    • Webcasts
    • Free Cybersecurity Events
      • Free Events Overview
      • Summits
      • Solutions Forums
      • Community Nights
    • Content
      • Newsletters
        • NewsBites
        • @RISK
        • OUCH! Newsletter
      • Blog
      • Podcasts
      • Summit Presentations
      • Posters & Cheat Sheets
    • Research
      • White Papers
      • Security Policies
    • Tools
    • Focus Areas
      • Cyber Defense
      • Cloud Security
      • Digital Forensics & Incident Response
      • Industrial Control Systems
      • Cyber Security Leadership
      • Offensive Operations
  • Get Involved
    Get Involved

    Help keep the cyber community one step ahead of threats. Join the SANS community or begin your journey of becoming a SANS Certified Instructor today.

    • Overview
    • Join the Community
    • Work Study
    • Teach for SANS
    • CISO Network
    • Partnerships
    • Sponsorship Opportunities
  • About
    About

    Learn more about how SANS empowers and educates current and future cybersecurity practitioners with knowledge and skills

    • SANS
      • Overview
      • Our Founder
      • Awards
    • Instructors
      • Our Instructors
      • Full Instructor List
    • Mission
      • Our Mission
      • Diversity
      • Scholarships
    • Contact
      • Contact Customer Service
      • Contact Sales
      • Press & Media Enquiries
    • Frequent Asked Questions
    • Customer Reviews
    • Press
    • Careers
  • Contact Sales
  • SANS Sites
    • GIAC Security Certifications
    • Internet Storm Center
    • SANS Technology Institute
    • Security Awareness Training
  • Search
  • Log In
  • Join
    • Account Dashboard
    • Log Out
  1. Home >
  2. Blog >
  3. Agile Development Teams CAN build secure software
Jim Bird

Agile Development Teams CAN build secure software

February 22, 2012

Agile Development Doesn't Create Secure Software questions whether Agile development teams can build secure code. It mostly references a study on small- and medium-sized Agile development teams, which found that Agile teams don't take security seriously even when building systems that are "web-facing and potential targets of attack". This isn't surprising. We already know that many development teams, especially small teams, do a poor job of building secure software. But is it Agile development specifically that is the problem?

Many security experts, especially those who work in or for enterprises, think it is. In Agile Development = Security Fail, Adrian Lane looks at the risks and problems in developing software following Agile methods from a software security perspective. And he finds a lot of them (as you can tell from the title of his talk). Let's look at these problems, and what they mean to Agile development teams.

Do Agile Teams Move too Fast to do a Good Job?

All development teams are under pressure to deliver as soon as possible, whether they are following incremental, iterative (capital-A Agile or small-a agile) methods or not. This pressure often leads teams to short-cut reviews and testing, including security work. Agile teams move especially fast — that's one of the main reasons to follow Agile development. Agile teams try to deliver working software to the customer quickly and often so that the team and the customer can make sure that the project stays on track. But Agile teams that follow good practices can deliver code that is reliable and high-quality, and still do this quickly — this is why so many teams have adopted or are adopting Agile methods today. Steve McConnell in Code Complete found that Agile teams following XP practices like pair programming and automated testing can achieve defect-removal rates of 90% on average and up to 97%, "which is far better than the industry average of 85 percent defect removal." If Agile teams can deliver high-quality code, why can't they deliver secure code?

Microsoft thinks that Agile teams can build secure software - they even explain how

Microsoft's SDL Agile breaks the set of security practices from their secure SDL down into steps that can be followed by Agile development teams working in sprints or time boxes. There are some steps that only need to be done once, usually at the start of a project — making sure that everyone on the team understands security and privacy requirements, making sure that the team is trained on secure development practices, setting up a way to track security bugs, and assigning a security lead for the team. There are practices that need to be followed all of the time, in each sprint — using safe libraries and frameworks, running static analysis tools, and doing threat modeling on new features. And other steps that the team should do as often as they can — testing and code reviews, design and code reviews, incident response planning.

SDL Agile shows that Agile teams can build secure software — they just do it differently. Just like everything else in Agile development, security problems and security practices have to broken down into smaller pieces — do less, but more often. Not trying to do things perfectly each time, because you don't have the time, and because you know that you will get another chance to do it again soon.

Iteration Zero — More work needs to be done upfront

Because attention to design and architecture upfront will pay dividends later, many (if not most) Agile teams start with an Iteration Zero — some time at the start of the project to get the team together, to choose the tools and frameworks that they want to start using and try them out, time to learn about the domain and to think through some of the design problems upfront, to get an understanding of risks and constraints. This is also the time to understand security and privacy and compliance requirements and governance requirements for the system and the project.

Security needs to be included in design and coding work from the beginning. This means that the development team needs software security training early on so that they understand secure design problems and risks going in, and so that they can take care of them by making the right design and platform decisions. For example, SQL Injection (one of the leading vulnerabilities, especially for web apps) can be prevented upfront by deciding against dynamic statements and using prepared statements with bind variables instead. It's a simple decision to make, and doesn't add to the cost of developing the system — but it's a decision that the team needs to know they need to make.

Taking small steps forward — Dealing with risks incrementally

With incremental, iterative development you lose the gating steps that are inherent to serial Waterfall development — the handoffs from design to coding, coding to testing. Security practices, like quality practices in Agile, have to be burned in to how the team works, done continuously, iteratively and incrementally instead. The team can use incremental Attack Surface Analysis to watch for changes to the system's security risk profile — to determine when they have changed the architecture or interfaces to the system in a way that could make the system more vulnerable to attack. When they need to do more testing or code reviews, or threat modeling.

Threat modeling doesn't have to be a big deal for teams that are building software incrementally and that know the code well. Most changes that can be done in a 1-week or 2-week sprint are small and incremental, and shouldn't take a lot of time to review even when you have changed the attack surface. Like all things in Agile development, the ceremony can be kept to a minimum. What is important is to always be looking for risks and threats, for what can go wrong.

Developers who are pairing can also look out for security bugs and risks while they look for other coding and design problems. Static analysis tools can be plugged into Continuous Integration to check for security vulnerabilities and other coding mistakes. And there is time in Agile development to make sure that changes to high-risk code (network-facing and customer-facing code, plumbing and security features) are manually code reviewed against security coding checklists.

The Whole Team

The idea of the Whole Team is that everyone works together and shares responsibility for the code. But security work — session management, encryption, the database access layer (the kind of code that you should be using a framework for anyways) — needs to be done by experienced, technically strong developers. Adrian Lane is right that it's foolish to let inexperienced developers work on security-sensitive parts of the system, at the very least without the help of experienced people who understand the risks and care about details, just like it is foolish to have them work on other technically complex or risky parts of the system.

Automated Testing isn't Enough

Many Agile teams rely on automated unit testing and acceptance testing to prove that the code works. But incremental, in-phase functional testing isn't enough in itself to build secure and reliable software. Adrian Lane makes a good point that developers aren't good at breaking their own code — developer testing tends to focus on proving that the code works. So somebody else (QA testers, outside security testers) need to try to break the system and look for holes through adversarial, exploratory testing, destructive testing and simulated attacks.
At some point you should pen test the running system. With iterative, incremental development, the system is a constantly moving target, changing every week or two. You can't pen test the system at the end of each time box — there isn't enough time. But you don't have to. Schedule a baseline pen test when there is enough key functionality in place to be worth testing, but early enough that you can learn from it and before you have built too much software that may need to be changed. And any time after you have made a big change to the architecture or the attack surface, based on risk.

Pen tests and other security reviews don't fit nicely into time boxes, but they don't have to — they can be run as parallel engagements especially if you are bringing in someone from outside to do the work. The team members who are needed to help out will need some time buffered from their sprint commitments, in the same way that some teams need to buffer time for support work.

Any problems found in security reviews and pen testing need to be added to the team's backlog and dealt with like any other bug. If it's a serious enough problem, it should be reviewed by the team as part of their retrospectives — not just how to fix the problem, but what it means to how they develop software, what changes they need to make to how they design, code and test software to prevent problems like this from happening again.

Security Sprints and Hardening Sprints?

Some people recommend security sprints: periodic sprints where the team focuses on security issues instead of delivering features. One type of security sprint is what Microsoft calls a security spike or "mini security push", where the team looks for security bugs and other bugs and problems in an existing code base before making any major changes. Find the bugs, review and triage them, identify high-risk areas of code that may need more testing or review (or even rewriting if the code is bad enough), and then decide what you will have to fix so that you can start with a stable and safe base.

Another kind of security sprint is a "hardening sprint": a sprint that focuses on fixing security problems found in a pen test or after running a static analysis tool for the first time, or after the team finishes their security training and wants to get their hands dirty, or after a security incident in production; as well as fixing operational problems and outstanding bugs, and reviewing and updating documentation.

Who is Responsible for Security: the Customer or the Team

Adrian Lane also talks about the central problem of Agile's Customer or Product Owner — that it's the Customer who drives the team's requirements and priorities, decides what gets done and what doesn't. Even a strong and well-intentioned Customer can't be expected to understand application security issues or how to build secure software. They already have too much on their plate. The Customer's job is to decide what the team builds and in what order — NOT how they build it. At most they should be responsible for helping the team to understand the system's security and privacy and compliance constraints and basic security-related features. Defining what information is sensitive and needs to be protected, what activities need to be logged and recorded and reported in the system, and helping to define rules like access control restrictions and entitlements.

Security isn't the Customer's responsibility. And there's no time or opportunity to force security from outside. An Agile culture doesn't support this well anyways. Adrian Lane talks about the "Chickens and Pigs" problem with Agile (especially Scrum) teams — outsiders like security and compliance aren't considered part of the team, they don't share in the outcome and can't force one.

This means that the real job of building a secure system has to fall to the development team — it's their job to design, build and deliver a system that works and that is reliable and secure. Just because many Agile teams building online web systems and games and mobile apps don't build secure software doesn't mean that they can't. There's no reason that Agile Development has to = Security Fail. The technical work, the commitment to quality and detail that is required to build secure software is the same, regardless of what development approach a team follows.

Share:
TwitterLinkedInFacebook
Copy url Url was copied to clipboard
Subscribe to SANS Newsletters
Receive curated news, vulnerabilities, & security awareness tips
United States
Canada
United Kingdom
Spain
Belgium
Denmark
Norway
Netherlands
Australia
India
Japan
Singapore
Afghanistan
Aland Islands
Albania
Algeria
American Samoa
Andorra
Angola
Anguilla
Antarctica
Antigua and Barbuda
Argentina
Armenia
Aruba
Austria
Azerbaijan
Bahamas
Bahrain
Bangladesh
Barbados
Belarus
Belize
Benin
Bermuda
Bhutan
Bolivia
Bonaire, Sint Eustatius, and Saba
Bosnia And Herzegovina
Botswana
Bouvet Island
Brazil
British Indian Ocean Territory
Brunei Darussalam
Bulgaria
Burkina Faso
Burundi
Cambodia
Cameroon
Cape Verde
Cayman Islands
Central African Republic
Chad
Chile
China
Christmas Island
Cocos (Keeling) Islands
Colombia
Comoros
Cook Islands
Costa Rica
Croatia (Local Name: Hrvatska)
Curacao
Cyprus
Czech Republic
Democratic Republic of the Congo
Djibouti
Dominica
Dominican Republic
East Timor
East Timor
Ecuador
Egypt
El Salvador
Equatorial Guinea
Eritrea
Estonia
Ethiopia
Falkland Islands (Malvinas)
Faroe Islands
Fiji
Finland
France
French Guiana
French Polynesia
French Southern Territories
Gabon
Gambia
Georgia
Germany
Ghana
Gibraltar
Greece
Greenland
Grenada
Guadeloupe
Guam
Guatemala
Guernsey
Guinea
Guinea-Bissau
Guyana
Haiti
Heard And McDonald Islands
Honduras
Hong Kong
Hungary
Iceland
Indonesia
Iraq
Ireland
Isle of Man
Israel
Italy
Jamaica
Jersey
Jordan
Kazakhstan
Kenya
Kiribati
Korea, Republic Of
Kosovo
Kuwait
Kyrgyzstan
Lao People's Democratic Republic
Latvia
Lebanon
Lesotho
Liberia
Liechtenstein
Lithuania
Luxembourg
Macau
Macedonia
Madagascar
Malawi
Malaysia
Maldives
Mali
Malta
Marshall Islands
Martinique
Mauritania
Mauritius
Mayotte
Mexico
Micronesia, Federated States Of
Moldova, Republic Of
Monaco
Mongolia
Montenegro
Montserrat
Morocco
Mozambique
Myanmar
Namibia
Nauru
Nepal
Netherlands Antilles
New Caledonia
New Zealand
Nicaragua
Niger
Nigeria
Niue
Norfolk Island
Northern Mariana Islands
Oman
Pakistan
Palau
Palestine
Panama
Papua New Guinea
Paraguay
Peru
Philippines
Pitcairn
Poland
Portugal
Puerto Rico
Qatar
Reunion
Romania
Russian Federation
Rwanda
Saint Bartholemy
Saint Kitts And Nevis
Saint Lucia
Saint Martin
Saint Vincent And The Grenadines
Samoa
San Marino
Sao Tome And Principe
Saudi Arabia
Senegal
Serbia
Seychelles
Sierra Leone
Sint Maarten
Slovakia
Slovenia
Solomon Islands
South Africa
South Georgia and the South Sandwich Islands
South Sudan
Sri Lanka
St. Helena
St. Pierre And Miquelon
Suriname
Svalbard And Jan Mayen Islands
Swaziland
Sweden
Switzerland
Taiwan
Tajikistan
Tanzania
Thailand
Togo
Tokelau
Tonga
Trinidad And Tobago
Tunisia
Turkey
Turkmenistan
Turks And Caicos Islands
Tuvalu
Uganda
Ukraine
United Arab Emirates
United States Minor Outlying Islands
Uruguay
Uzbekistan
Vanuatu
Vatican City
Venezuela
Vietnam
Virgin Islands (British)
Virgin Islands (U.S.)
Wallis And Futuna Islands
Western Sahara
Yemen
Yugoslavia
Zambia
Zimbabwe

By providing this information, you agree to the processing of your personal data by SANS as described in our Privacy Policy.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Tags:
  • DevSecOps

Related Content

Blog
powershell_option_340x340.jpg
Cyber Defense, DevSecOps, Digital Forensics and Incident Response, Cybersecurity and IT Essentials, Penetration Testing and Red Teaming
July 15, 2022
Month of PowerShell: Working with PowerShell Log Files
In this article we'll look at how we can leverage PowerShell's object-passing pipeline to parse and retrieve data from an IIS web server log file.
370x370_Joshua-Wright.jpg
Joshua Wright
read more
Blog
CloudSecNext Summit Visual Summary
Cloud Security, DevSecOps
May 3, 2022
A Visual Summary of SANS CloudSecNext Summit 2022
On May 3-4, thousands from around the globe tuned in for the SANS CloudSecNext Summit. We invited Ashton Rodenhiser to create graphic recordings of our Summit presentations. If you missed a talk or are looking to view the SANS CloudSecNext Summit through a visual lens, take a look at the recordings...
370x370-person-placeholder.png
Alison Kim
read more
Blog
DevSecOps
May 4, 2015
2015 State of Application Security: Closing the Gap
The 2015 SANS State of Application Security Analyst Paper and webcasts are complete. This year, Jim Bird, the lead author of the SANS Application Security Survey series, Frank Kim, and I all participated in writing the questions, analyzing the results, drafting the paper, and preparing the webcast...
Eric_Johnson_370x370.png
Eric Johnson
read more
  • Register to Learn
  • Courses
  • Certifications
  • Degree Programs
  • Cyber Ranges
  • Job Tools
  • Security Policy Project
  • Posters & Cheat Sheets
  • White Papers
  • Focus Areas
  • Cyber Defense
  • Cloud Security
  • Cybersecurity Leadership
  • Digital Forensics
  • Industrial Control Systems
  • Offensive Operations
Subscribe to SANS Newsletters
Receive curated news, vulnerabilities, & security awareness tips
United States
Canada
United Kingdom
Spain
Belgium
Denmark
Norway
Netherlands
Australia
India
Japan
Singapore
Afghanistan
Aland Islands
Albania
Algeria
American Samoa
Andorra
Angola
Anguilla
Antarctica
Antigua and Barbuda
Argentina
Armenia
Aruba
Austria
Azerbaijan
Bahamas
Bahrain
Bangladesh
Barbados
Belarus
Belize
Benin
Bermuda
Bhutan
Bolivia
Bonaire, Sint Eustatius, and Saba
Bosnia And Herzegovina
Botswana
Bouvet Island
Brazil
British Indian Ocean Territory
Brunei Darussalam
Bulgaria
Burkina Faso
Burundi
Cambodia
Cameroon
Cape Verde
Cayman Islands
Central African Republic
Chad
Chile
China
Christmas Island
Cocos (Keeling) Islands
Colombia
Comoros
Cook Islands
Costa Rica
Croatia (Local Name: Hrvatska)
Curacao
Cyprus
Czech Republic
Democratic Republic of the Congo
Djibouti
Dominica
Dominican Republic
East Timor
East Timor
Ecuador
Egypt
El Salvador
Equatorial Guinea
Eritrea
Estonia
Ethiopia
Falkland Islands (Malvinas)
Faroe Islands
Fiji
Finland
France
French Guiana
French Polynesia
French Southern Territories
Gabon
Gambia
Georgia
Germany
Ghana
Gibraltar
Greece
Greenland
Grenada
Guadeloupe
Guam
Guatemala
Guernsey
Guinea
Guinea-Bissau
Guyana
Haiti
Heard And McDonald Islands
Honduras
Hong Kong
Hungary
Iceland
Indonesia
Iraq
Ireland
Isle of Man
Israel
Italy
Jamaica
Jersey
Jordan
Kazakhstan
Kenya
Kiribati
Korea, Republic Of
Kosovo
Kuwait
Kyrgyzstan
Lao People's Democratic Republic
Latvia
Lebanon
Lesotho
Liberia
Liechtenstein
Lithuania
Luxembourg
Macau
Macedonia
Madagascar
Malawi
Malaysia
Maldives
Mali
Malta
Marshall Islands
Martinique
Mauritania
Mauritius
Mayotte
Mexico
Micronesia, Federated States Of
Moldova, Republic Of
Monaco
Mongolia
Montenegro
Montserrat
Morocco
Mozambique
Myanmar
Namibia
Nauru
Nepal
Netherlands Antilles
New Caledonia
New Zealand
Nicaragua
Niger
Nigeria
Niue
Norfolk Island
Northern Mariana Islands
Oman
Pakistan
Palau
Palestine
Panama
Papua New Guinea
Paraguay
Peru
Philippines
Pitcairn
Poland
Portugal
Puerto Rico
Qatar
Reunion
Romania
Russian Federation
Rwanda
Saint Bartholemy
Saint Kitts And Nevis
Saint Lucia
Saint Martin
Saint Vincent And The Grenadines
Samoa
San Marino
Sao Tome And Principe
Saudi Arabia
Senegal
Serbia
Seychelles
Sierra Leone
Sint Maarten
Slovakia
Slovenia
Solomon Islands
South Africa
South Georgia and the South Sandwich Islands
South Sudan
Sri Lanka
St. Helena
St. Pierre And Miquelon
Suriname
Svalbard And Jan Mayen Islands
Swaziland
Sweden
Switzerland
Taiwan
Tajikistan
Tanzania
Thailand
Togo
Tokelau
Tonga
Trinidad And Tobago
Tunisia
Turkey
Turkmenistan
Turks And Caicos Islands
Tuvalu
Uganda
Ukraine
United Arab Emirates
United States Minor Outlying Islands
Uruguay
Uzbekistan
Vanuatu
Vatican City
Venezuela
Vietnam
Virgin Islands (British)
Virgin Islands (U.S.)
Wallis And Futuna Islands
Western Sahara
Yemen
Yugoslavia
Zambia
Zimbabwe

By providing this information, you agree to the processing of your personal data by SANS as described in our Privacy Policy.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
  • © 2023 SANS™ Institute
  • Privacy Policy
  • Contact
  • Careers
  • Twitter
  • Facebook
  • Youtube
  • LinkedIn