Do you ever ask yourself ‘What the Fudge’ is going on in my apps?
Yes, I know you thought the acronym meant something else, but I am trying to keep this blog PG; but please feel free to define the abbreviation however you want.
It is an easy question to ask, but with today’s distributed development environments and aggressive CI/CD pipelines, it is not easy to answer.
How many people in your organization do you need to chat with to understand your apps’ architecture, technology stack, and security posture? I am guessing it is a big group of people who all have many responsibilities, so getting time on their schedule is challenging.
A holistic approach to WTFIGO is needed, but how do you get there? If you want to learn more, continue reading.
The Architect’s View of WTFIGO
As an architect, it is your responsibility to understand the ecosystem of your apps at the thirty-thousand-foot level. You know the technologies and the way your companies’ applications work but are not specifically responsible for the actual development or granular decisions of which technologies to choose to meet the requirements of the desired architecture.
I would compare an architect to the conductor of the symphony orchestra as they instruct people what to do and when but don’t play the instruments.
An architect would, for example, know that there are APIs and Open Source Packages in their application but not the specific details of what version or the comprehensive list of all the technologies.
From the WTFIGO aspect, they know the way their applications work but not everything about the applications.
The Developer’s View of WTFIGO
In today’s shifting landscape of cloud-native development and microservices architecture, developers work on their part of the application and assume that the developers working on the other parts of the application are doing their jobs.
Developers are no longer working on large monolith apps where everyone works on the application together. They stay in their lane, work on their functionality, and let the CI/CD process assemble all the components into the running app.
Developers may know what the other teams are doing in terms of functionality but do not understand how the required functionality is implemented. They “hope” that the PII data they are processing in a secure manner stays secure when passed off to the next level of application processing but don’t know.
Security’s View of WTFIGO
Security is in a tough spot as they are looking at their organization’s applications from the outside.
They can provide guidance and education on what a secure architecture looks like but are not directly responsible for implementing it. They must rely on AST scanning technologies like SAST, SCA, and DAST to find security issues in the code or running application.
Once they have the findings of these scans, they must look at them and decide if the risk fits their security policies. If it does, they then communicate them to the developers for remediation and hope they fix it correctly.
The only way to check is to restart the AST scanning process for verification. The security professionals know what security risk is and how to prevent it. Still, they typically do not know WTFIGO in their applications related to the risk.
But I thought DevOps was all about collaboration and knowledge sharing?
At its core, yes, DevOps is about collaboration and knowledge sharing, which allows people to perform many jobs within the process.
But in my opinion, this is more of a dream than a reality. Please don’t kill the messenger, as some organizations do a great job with this, but two variables complicate the perceived goal of collaborative DevOps.
Those variables are time and resources. CI/CD release processes are becoming more and more aggressive, so the time to understand every aspect is getting shorter and shorter. It is the nature of the beast that there is just not enough time for everyone to understand everything that is happening when you push a new release multiple times a day.
Now think about the other variable of resources, and when I say resources, I mean people.
To be blunt, it is challenging to hire people these days. I bet that your company currently has open recs for Application Architects, Developers, and App Security professionals they have been trying to hire for a while. There aren’t enough people to perform all work, so it is a bit crazy to think they would have the time to learn everyone else’s job.
The Solution to WTFIGO in My Apps
Instead of looking at your apps from your role or responsibility, you need a way to look at how everything works together, and that one simple change can introduce dangerous drift in your application.
Not to mention introduce significant security issues that were not thought of because people did not know WTFIGO in their apps.
Apps are changing daily, and the potential for unknown risk is more of an issue than ever before.
All I am offering is the truth, nothing more
To reference the Matrix, do you want to take the blue pill and continue the same path you are on and pretend that the aggressive CI/CD process isn’t introducing new and potential drift, compliance issues, or unmanaged services in your applications.
Or do you want to take the red pill and open your eyes to complete Application Risk Visibility?
Bionic can help if you choose to take the red pill.
Check out how Bionic visualizes application architectures: