ShiftLeft Shifts Security Focus to Analyzing Applications, Not Reacting to Threats – InApps is an article under the topic Software Development Many of you are most interested in today !! Today, let’s InApps.net learn ShiftLeft Shifts Security Focus to Analyzing Applications, Not Reacting to Threats – InApps in today’s post !
Read more about ShiftLeft Shifts Security Focus to Analyzing Applications, Not Reacting to Threats – InApps at Wikipedia
What if you could abandon trying to keep up with every security threat that comes down the pike and instead secure your applications at the code level?
That’s the thinking around ShiftLeft, a Santa Clara, Calif.-based startup focused on providing security at both build time and runtime.
“We’re developing a micro-agent specific to each version of each application, not by responding to threats, but by understanding the security needs of that version of the application,” said CEO Manish Gupta.
In the days of shrink-wrapped software, customers had no option but to provide perimeter security — firewalls, intrusion detection, antivirus, web application firewalls — since they had no access to proprietary source code, he explained. In 15 years in the security industry, most recently at FireEye, where he was seeing about 100,000 new pieces of malware a day, reacting to threats doesn’t make sense in an environment where development teams are releasing software multiple times a day.
At the same time, the assembling of components — a little bit of custom code, some open source software and third-party libraries — provides more opportunities for error and code weaknesses to be incorporated into multiple versions of applications.
ShiftLeft combines analysis of source code and runtime behavior of software.
At build time, ShiftLeft begins by determining what the company calls the “security DNA” of the application and creating a custom security agent used at runtime to protect that specific version of the application. That “DNA” includes what the software does, the open source software used, vulnerabilities, how it uses sensitive data and coding errors.
“If you understand that a microservice does not fork a process, if in production if it starts to fork a process, we know it has been exploited. We might not know what threat caused it, but by understanding the application through source code, then monitoring the production environment behavior relative to the source code, we can know when an application has been exploited or an unknown vulnerability has been leveraged to exploit the application,” Gupta said.
It’s a plugin or command-line interface when used with CI/CD tools such as Jenkins, Travis CI or Circle CI. Once the build is complete, it fetches external dependencies associated with the project, composes an archive file, and uploads it to a gateway server in the ShiftLeft cloud along with the organization ID and token metadata. All data from the gateway server to the ShiftLeft core system are encrypted and signed by the organization’s private key.
The micro agent is a JAR file that is attached to the deployment using a single command that includes the JAR path and the ShiftLeft gateway server address where runtime events and alerts are sent.
If using a deployment configuration tool such as Chef, Puppet or Ansible, use a command in the configuration file where the application is being provisioned. The micro agent monitors the application in runtime and sends events and metrics to the ShiftLeft gateway server via the ShiftLeft proxy, a Linux executable that can be installed on most Linux x64-bit distributions.
If for example, you have version 1.3 of an application and the initial scan finds 10 issues in the code, developers, for whatever reason, might fix only six of the problems, which becomes version 1.3.1. It’s not uncommon for companies to put both versions in production, Gupta explained. Then ShiftLeft would protect for the 10 issues in version 1.3 and only the four remaining issues in version 1.3.1.
“It knows what issues are in each version and the line in the source code where those issues are. If you deploy your application inside a virtual machine on AWS, as it boots up, the micro-agent knows issue No. 1 is in line 23, so it instruments itself there, and line No. 98 has issue No. 2, so it instruments itself there, and so forth,” he explained.
A dashboard maps the application’s flow through the lens of security, co-founder and CTO Chetan Conikee explained in a blog post. Policy-based logic can then be applied to the flow to track:
- all inputs and outputs
- input validation at the root of flow
- new flows added as the application evolves
- output encoding at edges of the flow
- cryptographic practices in the application
- how sensitive data is used in the application
The software adapts as your code evolves over time, identifying potential exploits, sensitive data leaks in your application and alerts on a negative drift, he said.
Feature Image: “Linux Password File” by Christiaan Colen, licensed under CC BY-SA 2.0.
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.