Application security cannot just be the "speciality" of the Information-security team
As a developer you are involved in two-week sprints, pre-planning, planning, estimation, “the-sprint-itself”, daily stand-ups, show-and-tell, and retro-spectives. And repeat…..
**Every developer** has to be application, system, and infrastructure security aware.**
Awareness is the important word here. You can never be an expert in every arena; a combination of network, application, operating system, AWS security champion. There are not enough hours-in-the-day.
> > * * * > >
Far better to apply common-sense. Look at how you can identify, and mitigate “against” risk. Take the time to understand how a (newly identified) risk will impact a system.
Risks, which are identified, defined, with (potential) resolutions, are better than risks which “get-away” (in other words, “swept under the carpet”.
We are not talking about identifying every single risk, bug, problem, issue, undocumented-feature and putting it in the backlog.
We are instead looking at identifying issues with “software, systems, and infrastructure”, which (if not identified) could lead to something more prominent.
“Keep-em-peeled”, in other words - be aware of what you are coding, configuring, or changing.
If you add an extra end-point to your restful web-service, how are you changing the attack-surface?
Introducing a new data-flow. How will the “whole” system behavior change?
Identify the inconsistency, change in behaviour, or risk. Investigate, and Suggest how the risk may be mitigated.
This may sound like common-sense, but it is important to “not just” identify a situation, but also how to reduce the risk.
It may not be as clear-cut as writing “a few more” unit tests….. Creativity may be required. Think about viewing a “situation” from several angles, **but **keep your feet “firmly-on-the-ground”, because that “is what” the business will want (bottom line).
Break a situation down into smaller (digestible) parts, and keeping (risk mitigation) solutions simple, and concise is the way forward.
This all comes from understanding how “the old”, and “the new” system behave.
**If you just want to cut code, please move along, there is nothing to see here.