Agile development and security: Are you doing it right?
© Shutterstock / Iconic Bestiary
Agile development is great for a lot of things. However, it’s
important to remember security issues in the development process. In
this article, Jessica Cyrus goes over the best ways to make sure
security concerns are adressed properly in the Agile development
process.
While we value the principles laid down in the original Agile
Manifesto released in 2001, we must now seamlessly integrate the
principles of security into the Agile environment. A decade or later,
things haven’t changed much in the software development corner of the
industry. Similar issues plague application security efforts. Security
is the Testing team’s responsibility and considered as separate from the
activities & planning that goes into the software development
process. Naturally, security features do not fit organically into any of
the software development activities.
Security specialists are just like experts in any other discipline, like performance or user experience, working to achieve goals in security. They are experts in building security tools seamlessly into the development toolchain and the CI/CD environment.
A good example of this principle is in the way security specialists coordinate with development teams. In theory, security specialists can walk their own path. But they need to use the same whiteboards, sticky notes, or online tools that the development team uses. Simply put, the security team needs to use the same planning tools that the software team uses to sketch out security goals.
When software asks a user to save passwords, or when it turns on encryption, etc., the user sees the inner workings of the software’s security. Software developers in any software development company in India Must choose to change the code to make secure software features rather than inadvertently allowing users to see how their software’s security works.
A holistic view of things that could go wrong is the best way to handle risk management, whether managing risk by writing some code; monitoring and reacting to bad behavior, using legal and contractual controls instead of technical controls, instead of making a never-ending list of individual bugs that need to be suppressed.
Most Agile teams fall into the trap of trying to go with the easiest fixes, which may include the dictum: “write the least amount of code that makes the security report go away.” Taking an all-rounder view of security risks negates that attitude. This would include looking at business processes, monitoring, legal contracts, etc. to discuss the risk to the business, not the just parts pertaining to coding.
The Agile Manifesto favors working software over reams of documentation, which does not mean it recommends forsaking documentation entirely. While risks must be mitigated, bugs to need fixing. With all things being equal, we cannot favor one component of the software development process over another.
Integrating security specialists into the development process
Very often, we don’t think about security as something that’s part of the software we’re building. Continuous Integration/Continuous Deployment (CI/CD) need not be put on hold for an external security review before moving forward.Security specialists are just like experts in any other discipline, like performance or user experience, working to achieve goals in security. They are experts in building security tools seamlessly into the development toolchain and the CI/CD environment.
SEE MORE: Agile machine learning: From theory to production
Integrating the security team into task planning
On a variant of the 1st principle, software developers must absorb security processes into software activities. When a software team is satisfied with the agile process they’re working on, security activities can become a part of that process, otherwise, it isn’t efficient at all.A good example of this principle is in the way security specialists coordinate with development teams. In theory, security specialists can walk their own path. But they need to use the same whiteboards, sticky notes, or online tools that the development team uses. Simply put, the security team needs to use the same planning tools that the software team uses to sketch out security goals.
Secure implementations instead of add-on security features
Due to constant add-ons, the security of any software evolves over time. Instead of concentrating on the business value of software and achieving its mission, we end up adding security features like authentication controls, password storage schemes, etc. that are best left to security specialists whose business is to handle security kinks.When software asks a user to save passwords, or when it turns on encryption, etc., the user sees the inner workings of the software’s security. Software developers in any software development company in India Must choose to change the code to make secure software features rather than inadvertently allowing users to see how their software’s security works.
SEE MORE: DevOps for IoT: Getting ready for the next phase
Fix security risks rather than bugs
Most software development activities include hunting for security vulnerabilities, fixing them, and terming the software as ‘secure’. While building software, security specialists & developers need to consider how to minimize risks to the business, the users, or the data. Only rarely is security as simple as fixing a bug. But frequently, it’s more complicated, with software & security specialists having to work out the right ways to deal with risk – prioritization risk management.A holistic view of things that could go wrong is the best way to handle risk management, whether managing risk by writing some code; monitoring and reacting to bad behavior, using legal and contractual controls instead of technical controls, instead of making a never-ending list of individual bugs that need to be suppressed.
Most Agile teams fall into the trap of trying to go with the easiest fixes, which may include the dictum: “write the least amount of code that makes the security report go away.” Taking an all-rounder view of security risks negates that attitude. This would include looking at business processes, monitoring, legal contracts, etc. to discuss the risk to the business, not the just parts pertaining to coding.
The Agile Manifesto favors working software over reams of documentation, which does not mean it recommends forsaking documentation entirely. While risks must be mitigated, bugs to need fixing. With all things being equal, we cannot favor one component of the software development process over another.
Comments
Post a Comment