In my previous post, Why baking security into products is important, I examined the reasons for pushing security leftwards in your development process. Assuming teams do this, how do you ensure security elements added earlier in the development process actually end up in production? Or more importantly, ensure that nothing is in production that shouldn’t be there. In other words, how do you prove your security and compliance process is achieving what it was intended to do. Once you have a security & compliance process that executes as required, it enables fantastic alignment between your development, operations, security, and audit teams. Outcome transparency is the foundation of building trust across your teams. Building this trust requires surfacing the data and demonstrating to your teams that the security & compliance processes have been implemented. Let’s take each of these elements of a sound security & compliance process in turn.
During development, you must not only implement security policies but also ensure adherence to those security policies. This is particularly important when dealing with large applications that have a large number of third party, usually open source, components. Typically you have policies around what components may or may not be used in the selection of components to build your solution. Quite often these policies are mandated by compliance requirements such as licensing or project quality. Once developers begin to use these components and they become part of your codebase the policies need to be maintained over the lifetime of the application.
And the versions of the components used in your solution can change either fast or slow depending on:
- the type of component
- the project’s overall development activity level
- their sensitivity to dependencies in their own dependency tree
- reliance on the underlying language features.
Consequently, knowing the components you have in your application, scaling this component knowledge across your entire application portfolio, combined with keeping track of those updates, is a tremendous effort. This can be effectively automated and offer value to development manager. Because when you can understand your reliance and, hence the risk on individual components, you can take action as well as put processes in place to mitigate identified risks. Further, being automatically notified of updates to your components empowers you to maintain continuous delivery and still keep your security goals front and centre.
What about production? How do you trust what you have running in production, particularly on a long-term basis? Once an application has undergone its verification procedure, usually in a quality assurance process – or at the very least an automated test suite, you are now limited with these results as being the final view into your application’s components. However, this last view lacks oversight on the challenges that occur in operations when configurations are different than other environments used in the software development process. In production, security, uptime, and stability are of paramount importance.
Proper security and audit policy is such that you should be able to prove that what is expected to be in production is in fact what ends up there at runtime. Being able to verify what you’re running in production should n’t need special code to be added to the original code, which would thereby save retesting and maintaining new code. In fact, if this verification could happen at runtime and offer instant reporting on what’s running across all your applications, then your team would now have the proof and oversight it was lacking: proof of security, governance, and compliance. What if…?
ActiveState has taken the ‘what if’ and made a ‘you can’. We’ve developed a Python runtime offering for our SaaS platform that provides a way to check your runtimes, go faster, and comply with your security requirements. Now you can:
Ensure Security at Runtime: security is built-in, embedded in the language interpreter.
Minimize Attack Surface: Use the packages you need. Identify what you don’t need.
Get a Key Risk Indicator Dashboard: See all security & compliance issues at a glance in real-time.
Profile Risk: Profile vulnerability & usage. Gain better triage at runtime.
Reduce Time to Detection: Track & update vulnerabilities in real time.
We’ll add runtime verification for additional open source languages, starting with the ones we currently support (Python, Go, Tcl, Perl and Ruby).
Working with Python? Want to prove your security and audit processes are in compliances with what’s running in production? Sound like something your DevOps, DevSecOps or Security Teams need?
Try it out in action – sign up for the ActiveState Platform today.
Sign up
