devopsy.kinsta.cloud

Tag: devsecops

GitLab Releases Massive Update to CI/CD Platform

GitLab has updated its continuous integration/continuous delivery (CI/CD) platform with a raft of capabilities spanning everything from value stream management to cybersecurity.

In addition, GitLab announced it is making generally available Gitaly Clusters, which enable DevOps teams to create a warm replica of a Git repository.

Brendan O’Leary, senior developer evangelist at GitLab, said with release 13 GitLab continues to build on a single code base that allows the platform to be managed and accessed as an integrated set of applications rather than disparate components that DevOps teams need to pull together and then manage.

In terms of core DevOps capabilities, the latest release adds the ability to customize the Value Stream Analytics module to specific workflows. GitLab is also planning to make it possible to visualize stages of a workflow.

GitLab is also improving traceability between requirements and has added the ability to visualize the workflow associated with a specific release. A future release will enable DevOps teams to employ feature flags to conduct both A/B testing based as well as create feature flags from merge requests and to filter feature flags by status, according to the company.

Other capabilities added include more customizable dashboards, with security dashboards now being shareable outside of GitLab to foster collaboration with IT security teams. Future releases will add Kubernetes Clusters to the dashboard to show all clusters and pods in use.

DevOps teams now can route existing monitoring alerts to GitLab for triage and incident resolution. At the same time, GitLab has moved design management to the core platform.

GitLab is also now making AutoDevOps, which provides pre-defined CI/CD pipelines, available on Amazon Web Services (AWS).

In terms of cybersecurity, GitLab has revamped the way the platform manages vulnerabilities to make it easier in a future update to prioritize remediation efforts.

GitLab also has static application security testing (SAST) support for .NET frameworks and has expanded support for offline environments. There’s also now support for dynamic application security testing (DAST) for REST application programming interfaces (APIs) and access to full commit history scan for secrets. Fuzz testing support will be introduced later this year, according to the company, along with an ability to secure secrets across services. GitLab also plans to add integration with security tools that track container behavior analytics, as well as an out-of-the-box container network policy.

Thanks to GitLab’s collaboration with Okta, there is now also tighter integration with Okta’s System for Cross-domain Identity Management, which can be provisioned for a GitLab group.

In terms of compliance, GitLab also plans to enable DevOps teams to establish a compliance framework, adopt its regulatory controls and simplify audit reporting. The company is also working on an initial security policy user interface to simplify setting up security guardrails.

Finally, GitLab has become a Common Vulnerabilities and Exposures (CVE) ID Numbering Authority (CNA). GitLab users can request a CVE from GitLab, either for GitLab itself or for any project hosted on GitLab.com. In the future, users can request CVE IDs directly from within GitLab.

O’Leary said GitLab is working toward increasing developer confidence in their security skills. By making it easier to embrace best DevOps practices, developers no longer will have to tiptoe around security issues that they today largely have little to no familiarity with, he said.

In general, O’Leary said GitLab’s biggest challenge is getting organizations to move beyond simply using it to manage source code. Once organizations do make their first foray beyond source code management, however, it’s not too long before they are employing a wide range of modules, he noted.

Of course, encouraging organizations to dive deeper DevOps has as much to do with the culture of the organization as it does the capabilities of the CI/CD platform employed.

May 26, 2020
The Best Approach to Help Developers Build Security into the Pipeline

Speed and agility are at the core of digital transformation and DevOps culture, and have quickly become a business imperative for organizations that want to remain competitive. Speed cannot come at the sacrifice of security, though. The pace of software development requires that security be baked into the code from the start rather than tacked on after the fact. Developing secure code fast requires empowering developers with the skills and tools they need and building security into the DevOps pipeline.

Embracing DevSecOps

DevOps culture and the drive to work faster and more efficiently affects everyone in the organization. When it comes to creating software and applications, though, the responsibility for cranking out code and producing quality code falls on developers.

The pace of DevOps culture doesn’t allow for anything to be an afterthought. It’s important for developers to support security directly as a function of application development in the first place, and to operationalize security within the continuous integration/continuous deployment (CI/CD) pipeline.

Unfortunately, traditional education does little to prepare them. It’s possible to get a PhD in computer science and never learn the things you need to know to develop secure code. As organizations embrace DevSecOps and integrate security in the development pipeline, it’s important to ensure developers have the skills necessary. You also need to focus on both the “why” and the “how” in order to build a successful DevSecOps training program.

Don’t Just Check the Box

Not all training is created equal. Consider why you’re doing the training and the outcome you hope to achieve rather than doing training for the sake of training. Many organizations focus on training developers in secure coding practices from the perspective of compliance. It’s crucial to engage developers in a meaningful way, though, and not just check a box.

Many compliance frameworks, such as PCI-DSS, require ongoing application security training, but compliance training often reinforces the wrong lessons. Developers learn the most expedient way to check the box and achieve compliance rather than learning the most efficient way to develop secure code. This approach also causes developers to feel like the security team looks down on them or doesn’t understand the challenges they face or the expectations they have to meet.

The Carrot and the Stick

How you do security is also important. Training works better when developers feel like they are part of the process and when they have a reason to want to excel.

For nearly everyone, doing something in practice reinforces lessons better than just reading content or listening to a webinar or video. Interactive labs are more engaging and provide feedback as developers go through the training. They can practice writing secure code with guided practice that is self-paced. They can also get hands-on experience exploiting vulnerable applications, then patching them back up.

You should implement developer training that creates incentives for developers by gamifying training. Create custom Capture the Flag events, track individual progress and provide a leaderboard that enables healthy competition among the developers.

You also want to provide developer training that is relevant to your organization’s preferred coding languages and business objectives. The training should teach skills and strategies that are applicable to the code your developers work with and give them tools they can use immediately to improve the security of the applications they’re working on.

Speed is essential for businesses to maintain a competitive edge today, and security is more important than ever. Make sure you have the training in place to help shift application security knowledge left and integrate security to mature DevSecOps practices.

May 25, 2020
GitLab Survey Sees DevOps Gains as Developers Exercise More Control

A global survey of 3,650 software professionals published by GitLab respondents indicates developers are exercising more direct control over IT environments.

More than a third of respondents (35%) said developers define and/or create the infrastructure their applications run on, with 14% actually monitoring and responding to infrastructure events. Additionally, 18% of developers instrument code for production monitoring, while 12% serve as an escalation point when there are incidents.

More than 25% of developers reported feeling solely responsible for security, while 33% of security team members say they own security. A total of 29% said they believe everyone should be responsible for security.

A quarter of respondents said their organizations have been practicing DevOps for three to five years, while 37% said they have been practicing for one to three years. Nearly 60% of respondents said their organizations deploy code either multiple times a day, once a day or once every few days, a 15% increase over the previous year.

Brendan O’Leary, senior developer evangelist for GitLab, said that massive jump in the number of organizations capable of deploying code at faster rates indicates many more organizations are starting to move further along the DevOps maturity curve. For example, the survey finds 70% of developers can now provision their own IT environments.

Well over a third of respondents (38%) said their DevOps implementations include a continuous integration/continuous delivery (CI/CD) platform. Almost 59% of those surveyed use GitLab, while 23% use GitHub and 11% use BitBucket. For builds, 60% use GitLab and 38% use Jenkins. A total of 29% said their DevOps implementations include test automation, while 16% said they have embraced DevSecOps.

Almost 40% of survey takers said they “partially” use microservices, while a quarter (26%) said they fully use them. Well over a third (38%) have also adopted Kubernetes.

Despite that progress, however, the survey makes it clear there is still much work to be done. More than 42% said testing still happens too late in the life cycle. In fact, 47% identified testing as the top DevOps bottleneck for the second year in a row. Only 12% said they have completely automated testing.

When it comes to security, well over a third (36%) find it hard to understand, process and fix any discovered vulnerabilities. About a third (31%) said prioritizing vulnerability remediation is still an uphill battle.

O’Leary said when it comes to security the most challenging issue remains determining what vulnerabilities to prioritize alongside a long list of other bugs and issues that often need to be addressed. Cybersecurity teams all too often continue to send developers a list of vulnerabilities they have discovered with no context, he noted. Many developers are only made aware of an issue after their code has been merged, which O’Leary said makes it more difficult for them to address a specific security issue.

It’s not clear any organization will ever achieve complete DevOps nirvana. However, as organizations become more proficient it’s clear the return on investment in DevOps is starting to be achieved as more organizations deliver code faster. The challenge now, of course, is making sure the right secure code is delivered at the right time.

May 18, 2020
The Secure Software Development Life Cycle: Syncing Development and Security
Over the last five to 10 years, the nature of software development has shifted dramatically. Whereas large software releases occurred every six to 18 months in the past, current release schedules have become much more frequent. The waterfall model of software development has morphed into what we now know as the DevOps model.

As a consequence, DevOps has instigated changes in the traditional waterfall security touchpoints. In essence, DevOps has changed the very nature of how application security needs to be implemented. To avoid friction in the development process, application security activities must be adapted to the new world of DevOps practices. It has to go beyond the basics of threat modeling, design review and two weeks of pen testing.

Under DevOps, some development organizations now do software releases on a daily, weekly or bi-weekly cadence. But they’re still grappling with older application security models. As a result, development and security testing can be out of sync—you cannot conduct a two-week pen test on software that’s released weekly. These organizations need effective security assurance in their SDLC that’s good, quick, early and—above all else—automated.

The Changing Nature of Software Development

The way software is developed keeps changing. And it keeps accelerating. Application security needs to change to catch up. Automation will play a key role in enabling application security to maintain the pace of DevOps. DevOps needs automation to effectively deal with software release cadences that occur on a daily, weekly and bi-weekly basis as well as to increase agility generally within the SDLC.

For example, DevOps accelerates when the automated pipeline embeds application security scanning into pre-commit checks. In this way, consistent levels of application security testing apply every time developers check in code, resulting in a fully automated check-in process. But automation doesn’t lock developers into the same level of security for every code change. For example, if the change only involves altering the color of a logo, heavy security scanning and manual won’t be necessary. At least not the way it would be if the application is accessing sensitive data.

So, instead of giving developers quarterly SAST results, automation puts the code analysis right there in front of developers as they’re checking in code (via certain IDE plugins). Presenting the code analysis findings to developers, while they are still in the code, has several advantages:
- The code is still fresh in the developers’ minds.
- Coding problems can be caught earlier and more easily while developers are still thinking about the code.
- It mitigates the risk of developers not remembering the code context at a later date.
Overall, the more automation there is in application security the better it is for open source validation, container scanning containers, QA testing, API security and more.

Automated Security Assurance and Out-of-Band Activities

When it comes to implementing testing in DevOps, you must balance automated security assurance with out-of-band activities. That means it’s sometimes appropriate to slow down the automated security process. Even in a completely automated DevOps process you may need to slow down to make necessary changes. It’s true a code change, such as just changing the background color on a web app, may not be too risky. There’s no problem with automating that DevOps step and pushing out the change. But, if your web app interacts with customer data, you’d be prudent to slow down and take the next application security test out of band, and make sure you’ve got the procedure right because it’s much riskier.

There are different levels of risk and severity within each release of an application. Development organizations need to accept this and adapt to each release’s potential risk and severity level. Then, they need to provide the appropriate level of security assurance and security coverage, whether that is automated within the DevOps workflow, performed out of band or some combination of the two.

Life in the Fast Lane

For DevOps organizations, one of two avenues beckons to them: the security express lane or the security slow lane. You could create an automated DevSecOps process across the development organization—the security fast lane. But, there’s no one-size-fits-all DevSecOps process for enterprises. That’s because there could be up to hundreds of development teams within an enterprise. And there’s not always a standardized process that all dev teams can follow. It’s a challenge to adapt automated security to each development team. Those in the security fast lane should use a security champion to work with the development team and be the point person to assist them with understanding application security needs and remediation guidance.

In the security slow lane, individual development teams may still be enabled to go fast. The difference is that they will pick the SDLC tools that make the most sense for that team. Then, they should also pick the application security tools that make the most sense for them. The bottom line for organizations is that application security needs to involve an acceptable level of friction for developers to make DevSecOps work. If there is too much friction, developers will bypass application security in favor of expediting coding activities.
May 13, 2020
Survey Surfaces Root Causes of DevSecOps Tension

Results of a survey published by SaltStack, a provider of IT automation tools, suggests tensions between cybersecurity and IT professionals on the one side and DevOps teams on the other are running high. According to the survey of 130 cybersecurity and IT leaders, 70% of respondents said their organization is sacrificing data security for faster innovation, with most cybersecurity and IT managers making a case for prioritizing data protection over innovation, speed to market and cost.

Alex Peay, senior vice president for product at SaltStack, said that while it’s unlikely cybersecurity and IT leaders will be able to slow down the pace of innovation within their organizations, the survey results make it clear IT organizations are struggling to keep pace.

On the plus side, the results also show that cybersecurity and IT operations teams are working more closely together. More than half—54%—of cybersecurity leaders said they communicate effectively with IT professionals, while 45% of IT professionals concurred.

Best DevSecOps processes are, of course, meant to bridge the divide between DevOps teams and the rest of the IT organization. The expectation is that by pushing more responsibility for cybersecurity to the left, the pressure on cybersecurity and IT teams would be reduced. However, DevSecOps adoption remains nascent at best—many DevOps teams still don’t have the tools required to implement security controls programmatically within their applications.

Even when they do have the tools needed to add security controls, organizations need to set up workflows that will enable cybersecurity teams to verify that those controls have been properly implemented. Given the chronic shortage of cybersecurity expertise, the rate at which applications are being deployed and updated easily overwhelms the amount of time cybersecurity teams have available to analyze modules of code that are now often updated several times a week. Most cybersecurity teams are already struggling to keep pace with patches for existing applications, let alone any new application modules.

Of course, there’s not a lot of love lost between developers and cybersecurity teams. DevOps teams generally blame cybersecurity teams for slowing down the rate at which applications are deployed. In fact, one of the primary reasons DevSecOps is gaining traction among developers is that it represents a way to remove cybersecurity professionals from the application development process.

Cybersecurity professionals, conversely, often view application developers as the root cause of the cybersecurity problem. Too many developers are reusing modules of code without first making sure those modules have been updated to address a known vulnerability. To add insult to injury, whenever a new vulnerability is discovered days, weeks or even months may go by before developers address it. To be fair, however, cybersecurity professionals are not especially adept at prioritizing vulnerabilities; as far as developers are concerned, the list of vulnerabilities presented is just one in a series of bugs that need to be addressed. Unless otherwise directed, developers will focus on bugs that impact features and performance before a potential security issue that has yet to manifest itself as an issue impacting end users.

In general, advances in DevSecOps are being made that should provide some much-needed relief to IT and cybersecurity professionals. It’s just slowing down the rate at which applications are deployed and updated might not be one of them.

May 7, 2020
GitHub Extends Scope and Reach of Repository

GitHub today at its GitHub Satellite virtual conference announced it has made it easier for developers to either launch a project or join an existing project on its repository and has added collaboration tools directly within the platform.

GitHub is also moving to advance DevSecOps by adding code scanning tools and making secret scanning tools available for private repositories, in addition to making available GitHub Private Instances to provide organizations in highly regulated industries access to a more secure managed implementation of the GitHub repository.

Max Schoening, VP of Product Design, said GitHub Codespaces removes a lot of friction associated with starting or joining a project by enabling developers to spin up a project in seconds. In many cases, he said, developers never launch a project simply because the effort required was too great relative to the value of the effort.

Available in limited public beta, GitHub Codespaces should not only improve developer productivity but also significantly increase the number of projects being hosted on GitHub, said Schoening.

GitHub Discussions, meanwhile, will provide a threaded format to organize unstructured conversations without having to leave the GitHub repository. Scheduled to be available in beta shortly, GitHub Discussions should increase developer productivity in addition to providing a place for developers to maintain a frequently asked questions document. Over time, Schoening said GitHub expects millions of communities to be formed around GitHub Discussions.

GitHub is also moving to make DevSecOps a natural extension of any application development project. GitHub Advanced Security Cloud provides access to native code scanning and secret scanning tools that can be embedded within the developer workflow. Currently in beta, GitHub Advanced Security Cloud is based on security tools it gained via its acquisition of Semmle last year. Every Git push can now be scanned using a CodeQL semantic analysis engine to discover vulnerabilities. GitHub Advanced Security Cloud is designed to be an extension of an existing GitHub Advanced Security service.

Finally, GitHub Private Instances will provide a fully managed alternative that, among other things, allows for bring-your-own-key encryption, backup, archiving and compliance with various regional data sovereignty requirements. GitHub did not reveal, however, when GitHub Private Instances will be available.

As GitHub continues to evolve as an arm of Microsoft, there is no doubt more IT teams will be embracing DevOps. The biggest challenge is often making it easy to get started. In fact, many developers may find themselves unconsciously embracing best DevOps and DevSecOps processes as they, for example, employ scanning tools baked into the GitHub repository.

Of course, no one knows for sure whether organizations will continue the pace of application development projects in the wake of the economic downturn brought on by the COVID-19 pandemic. However, Schoening noted the amount of time between pull requests has declined on the GitHub repository, which he suggests is an indication of increased activity and productivity now that more developers are working away from the office.

May 6, 2020
Your Applications Are the Weakest Security Link

Amazon, Microsoft and Google have much bigger security budgets than you do. They have hundreds of people all over the world ensuring that their infrastructure is secure. Their teams are constantly reviewing their code, looking for flaws, vulnerabilities and potential exploits. They monitor hacking forums and run attractive bug-bounty programs in order to remain proactive.

Only a few years ago, kernel errors were prevalent. Now, Microsoft’s and Linux’ teams have nearly eliminated kernel vulnerabilities. For example, according to the CVE database, in 2017 Linux kernel had 169 code execution vulnerabilities, in 2018 only three and in 2019 just five.

When it comes to the cloud platforms, the cloud providers indeed take responsibility for security of the cloud, while the customers remain responsible for security in the cloud–which is where the danger lasts.

Solution architectures are distributed across public cloud and legacy on-prem environments. They contain the customer’s own software as well as open source and third-party products, over which the customer has no control. Proliferation of microservices significantly increases the amount of network interfaces. Growing release velocity leaves no time to identify and address potential security problems and configuration oversights.

While the operating systems and critical infrastructure software are improving, the number of vulnerabilities in application software are growing quite significantly. The ability to alter existing applications or inject additional code allows attackers to turn legitimate software into malicious ones. This kind of vulnerabilities is listed in the “code execution” category, which happens to be the biggest group in the CVE database.

Patching known vulnerabilities takes more than 50 days on average, while attackers need just a few minutes to utilize them. On top of this, there is a huge amount of unknown/unpublished zero-day vulnerabilities, frequently used by commercial attackers who pay for them and keep them to themselves.

In the well-known Equifax data breach, malicious software infiltrated a legitimate web server using an Apache Struts vulnerability that allowed arbitrary code insertion. Since this attack occurred in 2017, the CVE database shows that Apache Struts has had at least five similar types of vulnerabilities.

Basically, customer applications are and will always be the weakest and the most exploitable software. How do we protect them?

Code execution vulnerabilities are exploited while the software is running. Some of the exploits do not leave any file system footprint at all—fileless malware. The exploit may happen days, or even months, into the execution session. The only reliable way to identify a break-in is to verify the software integrity in the same memory where the code is running throughout the entire execution session. Any change to the code or an addition of the unsigned code will compromise its integrity and therefore will be identified.

Traditional, file-based, signature mechanisms will not help here, because the executable files are changed when they are loaded into the memory; therefore, it must be a special algorithm sufficiently robust to protect itself and the application software.

Cryptographic signature uniquely identifies software just like human DNA identifies a person. This mechanism can be further used to provide applications with proper authorizations such as communication and information access. This will ensure that only applications with the right “DNA” can communicate with each other and access encrypted information, which is the ultimate Zero-Trust paradigm.

May 5, 2020
Securing Internet-Facing Portals

Against the backdrop of the current pandemic, barely a day goes by without another portal or web application being launched to help citizens and customers interact with governments and corporations. Bringing these applications to market quickly, and ensuring they can’t compromise the security of the organization, requires DevOps to embrace news techniques and technologies. So, how best can DevOps ensure these applications don’t become a backdoor for the bad guys?

Additional Defensive Techniques

In the OWASP Top Ten list of vulnerabilities in Web Applications, ensuring uploaded documents and images are threat-free doesn’t factor. Yet, these can be the Achilles Heel of any internet-facing portal or application.

The primary vehicle for smuggling malware into an organization is via documents and images. These are routinely embedded with malware, some basic, some extremely sophisticated, targeting the user or employee who eventually uploads the document. Alternatively, the concealed malware can attack the portal itself, for example, via a malformed document.

This malware is sufficiently new and well-concealed that it repeatedly evades detection-based cyber defences and even modern AI technologies. Ensuring that what arrives via the portal is threat-free means finding additional defensive techniques that increase the security without slowing down the application.

Best Practice

The UK’s NCSC has published a set of essential guidelines for anyone charged with the security of an application that must accept documents and images from the internet. In the NCSC “Pattern: For Safely Importing Data,” the organization describes a set of best practice guidelines for accepting documents from untrusted sources and recommends an approach called document transformation to ensure imported documents are threat-free.

Transformation is a mechanism whereby untrusted documents and images have the essential business information extracted from them. The originals are then discarded–along with any embedded threats. The business information is then verified and brand-new documents are then created and formatted to match the originals.

Figure 1: Transformation engine.

Once documents have been through the transformation engine they are completely safe and can be used without any further security measures.

“Baked-in” Security Controls

For the AppSec manager, transformation is a great approach to promote across DevOps teams. It can be accessed via cloud APIs and it adds an additional layer of security–conformant with security best practices–that helps ensure web applications and portals don’t become a backdoor for malware infiltration.

Figure 2: Uploading a Document via an API.

Developers need a choice of transformation APIs, depending on the nature of the particular application. For example, some applications will require a simple upload/download API to transform a file, while other applications will need APIs capable of handling more complex tasks, such as event-driven workflows or moving files between different storage buckets.

Figure 3: AWS Flow Using S3 API.

Head Start

The demand for web applications to accept uploaded documents into portals is only going to increase, and with it the risk of potential for compromise from concealed malware. The good news is that any DevSecOps professional building a web application or portal that must accept documents and images from the internet, already has a head start when it comes to building securely if they are using a serverless architecture.

From a security perspective, the alternative to serverless architectures, machine images in the cloud, have the associated risk that if, for example, malware succeeds in compromising the machine, it remains compromised thereafter. With a serverless, cloud native architecture, there is no residual machine and, therefore, little residual risk.

Another key point in favor of building on a serverless cloud-native computing model is that it devolves the responsibility of patching to the service provider. It is widely understood that unpatched systems are one of the main causes of cybersecurity breaches. Serverless architectures enable the developer to shift operational responsibilities and routine security tasks, such as patching, maintenance and upgrades, to their service provider.

The current pandemic has turbo-charged the demand for internet-facing portals and with it the risk of malware infiltration via uploaded documents and images. For developers, that means finding new defensive techniques like transformation that can be quickly and easily baked into the code to ensure uploads are threat-free.

May 4, 2020
One Identity Allies With HashiCorp to Advance DevSecOps

One Identity, a provider of identity management software, has aligned with HashiCorp to make it easier for DevOps teams to implement best DevSecOps practices.

Tyler Reese, a senior product manager for One Identity, said via a plugin for HashiCorp Vault developers can now securely manage, monitor, record and audit privileged and administrative access to their vaulted tokens, passwords, certificates, application programming interface (API) keys and other secrets residing in the Safeguard privileged access management (PAM) platform from One Identity.

The goal is to make it easier for developers to securely access credentials stored within Safeguard without having to provide access to every credential used to access, for example, a packaged application that a developer is trying to provide access to via a custom application or vice versa, he said.

The two companies are trying to bridge the divide between end user credentials managed by IT teams that have control over access to packaged applications and the way DevOps teams manage secrets within their custom applications, said Reese. DevOps teams increasingly need to integrate custom applications with packaged applications. The challenge organizations face is finding a way to securely provide that access in a way that doesn’t require internal IT teams to be overly involved in the application development process, he noted, adding by integrating with HashiCorp Vault, all the friction is taken out of the process.

Based on a transparent protocol proxy software that inspects protocol traffic at the application level, Safeguard rejects traffic that violates policies defined by the internal IT team. That approach prevents unauthorized and unfettered access to data. IT teams can also monitor privileged sessions in real-time with the ability to execute various actions, such as terminating a session if unusual or unwanted behavior is detected. Safeguard also enables IT teams to rotate privileged access passwords to comply with a wide range of regulations, said Reese.

As developers embrace DevSecOps they need to find a way to dovetail their efforts with existing password management processes. For the most part, DevSecOps remains aspirational within most organizations. There is general agreement that more responsibility for security should shift left toward developers. However, most organizations are still a long way from putting the tools in the hands of developers who need to extend existing DevOps workflows. In the absence of those processes and tools, DevSecOps often winds up being little more than a sermon that IT leaders give to development teams.

On the plus side, the rate at which cybersecurity tools that are integrated with the continuous integration/continuous delivery (CI/CD) platforms on which DevOps processes depend is steadily increasing. As that trend continues to gain momentum, the relationship between developers and cybersecurity teams will evolve. Cybersecurity teams will continue to define controls and verify that they have been implemented. Developers will be held accountable for implementing those controls as part of the overall quality assurance process. The challenge now is getting everyone inside behind that cultural transition in advance of the tools that will be available soon.

April 30, 2020
Accurics Makes Infrastructure as Code More Secure

Fresh off raising $5 million in funding, Accurics today launched a platform that analyzes the code employed to manage infrastructure as code for vulnerabilities as well as indicators of drift to create a threat model for cloud application workloads and then, if necessary, automatically roll back cloud settings to their last known approved state.

Accurics CEO Sachin Aggarwal said rather than simply focusing on cloud infrastructure, the startup company’s platform analyzes vulnerability feeds, identity access management (IAM) privileges and other data to detect potential cloud security issues. That analysis can then be shared with third-party security tools to automate remediation, he said.

Once the model is constructed, Accurics then monitors the application workload for changes that introduce risks and generates a topology for each workload in real-time to identify any potential indicators of drift away from the initial deployment settings. If the drift is due to a legitimate change, the code can be updated. If it introduces risks, IT teams can roll their code back to the last known secure posture using a “time machine” capability that Accurics has baked into its platform, he said.

The Accurics platform takes a different approach to cybersecurity—rather than focusing solely on application programming interfaces (APIs) exposed by cloud infrastructure providers, it analyzes everything from the Terraform code used to programmatically install workloads to the container and serverless computing frameworks employed. In the future, Aggarwal said Accurics plans to add integrations with other infrastructure commonly employed in cloud environments, including Jenkins, Bitbucket and GitLab continuous integration/continuous delivery (CI/CD) platforms.

That analysis surfaces violations of common compliance and cybersecurity practices based on Security Operation Center (SOC) 2, General Data Protection Rule (GDPR), Payment Card Industry (PCI), Healthcare Information Portability and Accountability (HIPAA), International Organization of Standardization (ISO), Center for Internet Security (CIS) Benchmark, Amazon Web Services (AWS) Best Practices and the AWS well-architected framework.

Aggarwal said Accurics advances DevSecOps by making it possible for organizations to continuously assess changes within their cloud application environments. Most of the issues involving cloud security today can be traced back to errors made while using tools to programmatically provision cloud infrastructure. The Accurics platform helps developers and cybersecurity teams to collaboratively discover those issues, he noted, adding the overarching goal is to enable both teams to reduce risks by eliminating the most common mistakes that are made in cloud computing environments.

As the relationship between DevOps and cybersecurity teams continues to evolve, it’s become apparent the first issue most organizations need to address when it comes to cloud security is visibility. Most IT teams are concerned about cloud security not because the platforms are less secure than on-premises infrastructure. In general, cloud infrastructure is more secure. However, because of a lack of visibility, it’s not as easy for cybersecurity teams to discover when misconfigurations create a known vulnerability. If that issue gets resolved, much of the resistance to cloud computing generated by security concerns will fade away.

April 28, 2020