devopsy.kinsta.cloud

Author: Mark Hermeling

  • A Seven Point Checklist for Getting SAST Right

    A Seven Point Checklist for Getting SAST Right

    With so many physical products—from automobiles to airplanes and medical devices to industrial control systems—now being driven by software, product security has become a top-level concern for manufacturers. Software flaws can not only affect security by introducing vulnerabilities that can be exploited by attackers but also impact safety by compromising a product’s functional operation.

    In addition, product security has significant financial implications. For example, fixing a vulnerability in development costs 10 times less than in testing and 100 times less than fixing it in production. This explains why static application security testing (SAST) has become a cornerstone of product security and the engine for implementing code analysis at the earliest stages of development, commonly known as shift left security.

    Unlike other forms of application security testing (AST), SAST scans 100% of the code, including configuration files, not just the code that is executed at runtime. SAST can also provide additional benefits, such as quality and architectural testing. Software quality and security are inextricably linked since poorly written software typically is insecure software.

    With the stakes so high, getting SAST right is the tipping point for any product security program. To evaluate SAST tools, consider the following checklist to make sure they align with your business requirements:

    1. Deep Language Support: C/C++, Java, C#, etc.

    Languages are often selected based on the programmatic requirements of the software producer, the needs of the consumer and the hardware associated with the product. For example, developing software for safety-critical applications like aerospace requires different capabilities than languages used to build web applications.

    2. Compiler and Embedded OS Platform Compatibility

    Compilers used for embedded software development implement unique flags for configuration, such as performance optimizations, code size, error checking and the diagnostic information emitted. Since embedded OS platforms typically include compiler and debugging tools plus the various OS files and configuration options, make sure the SAST tool can integrate with the development environment used.

    3. Actionable Alerts

    For the DevOps team to embrace security, embedding security in the software factory life cycle cannot slow down development velocity or hinder developers’ ability to meet software release timelines. False positives redirect developer attention away from writing software to investigating potential defects. Too many false positives result in developers losing faith in true positives and paying less attention to security alerts of real substance.

    4. Built-In DevOps Integration

    The software development life cycle employs an extensive toolset that provides automation to help developers get products to the production stage faster—not unlike a manufacturing plant or factory. Make sure the SAST tool supports and integrates with distinct tool categories including collaboration and management, source control and repositories, IDEs, compilers, orchestration and automation and business intelligence.

    5. Flexible Deployment

    Depending on the organization and industry, SAST may need to support a variety of deployment options, including on-premises, cloud, hybrid, etc. For example, air-gapped deployments are often required in security-sensitive environments where the data protection uncertainty associated with multitenant public clouds is unacceptable. Meanwhile, cloud-based SAST can provide benefits like scalability and elasticity and reduce infrastructure capital investments.

    6. Developer-friendly UI

    Shift left security is accomplished by integrating security warnings into the integrated development environment (IDE) used by engineers. A SAST tool that works within existing IDEs can reduce the number of errors presented to testers, which subsequently reduces the volume of kickbacks to engineering and leads to faster time-to-market.

    7. Standards

    Many organizations use—and some must comply with—standards for software coding best practices such as SEI CERT, MISRA, etc., which provide a framework for improving the safety, reliability and security of software systems. In addition, a company may need to satisfy functional safety standards such ISE 61508, as well as derivative industry specific standards including IEC 62304 (Medical), ISO 26262 (Automotive),  DO-178C (Avionics) and IEC 62434 (Security). A SAST tool should provide integration with key standards that govern an organization’s products and, where appropriate, be certified for them.

    Using these guidelines for evaluating SAST tools will help ensure that the product you select meets your organization’s business, technology, safety and security requirements.

  • Three Ways to Speed up SAST

    Three Ways to Speed up SAST

    In modern, continuous software development life cycle (SDLC) processes, when code is written and before it’s committed to the repository, it’s run through testing, which may include unit testing, regression testing or static application security testing (SAST). The benefit of SAST for DevSecOps is the real-time feedback it provides developers as they create and make changes to the source code before they submit it. The amount of time that’s acceptable in this kind of workflow is 15 minutes to 30 minutes maximum, with some allowance for how big the change is. Fast feedback means quicker turnaround and more progress on features. The business value lies in those features. Testing makes sure they work.

    Depth Versus Breadth

    Checkers used by SAST are not all created equal, at least in terms of the computation power needed. The time for analysis is directly related to the complexity of the checkers used to detect certain types of vulnerabilities. Typically, coding standard enforcement rules are easier to compute versus complex tainted data analysis used to detect command or SQL injections, for example. Therefore, there is a trade-off to be made in the types of bugs and vulnerabilities being detected. When developers are coding, it makes sense to optimize the compute time for SAST to reduce any delays. During software builds, more time and compute power is available so depth and breadth can be increased to catch complex vulnerabilities.

    Compute Power

    SAST analysis time scales well with compute power. The availability of more computing resources such as CPU and memory, can impact the time of analysis. Bigger is better in this case and investing in additional hardware for SAST can pay off in terms of productivity.

    Codebase Size

    SAST analysis time is also dependent on the amount of source code analyzed. Depending on the application, the code base is a determining factor in terms of what depth and breadth of analysis is optimal.

    There is some correlation between small code base size and strict requirements for SAST such as in safety-critical software. It’s expensive to build and test safety-critical code, but code size is typically smaller than in other types of applications. However, these products need to conform to industrial coding standards and thus require rigorous levels of testing and analysis to detect a wide variety of defects.

    Larger and extremely large code bases require a trade-off in terms of depth and breadth of analysis. Prioritizing the types of defects and vulnerabilities to concentrate on is critical.

    Speeding up SAST means reducing the amount of work. The most intensive operation is a full analysis of the entire source code base. Just as full compilation from scratch takes a long time, the same is true of SAST analysis.

    To accelerate SAST processing times, follow the same three techniques used to avoid compilation in large C/C++ projects: incremental analysis, component analysis and developer analysis.

    1. Incremental Analysis

    Incremental builds are a major factor in reducing developer build times for C and C++ projects. Small changes don’t require the entire code base to be recompiled. It’s impractical and unnecessary. When a developer modifies something, only what’s needed to be recompiled gets recompiled automatically, and the build infrastructure handles it.

    SAST works in a similar manner. As source code is being compiled, SAST parses the same source code and creates a program model. The second phase is analyzing that program model against the configured checkers and generating warnings. The warnings typically go into a database for later analysis.

    During the build of the software, SAST is run in parallel. Although similar to a compiler in operation, SAST must do more work than the compiler and takes longer to finish and provide results. The amount of code needed to recompile for each change directly impacts analysis time.

    Meanwhile, SAST of an incremental build requires a lot more work than just analyzing the changes. SAST uses abstract execution of code flow through multiple different compilation units. So even though a single file is modified, the calls it makes to other files need to be analyzed as well. The incremental analysis doesn’t increase the build and parse workload, but the analysis scope will be a lot bigger than expected. So, whenever you do an incremental build, SAST will need to reanalyze the dependencies, changes and related bits and pieces around those changed units.

    Nevertheless, it remains a good option for reducing SAST analysis times.

    2. Component Analysis

    If the software being developed has a loosely coupled, component-based architecture with well-defined interfaces, it’s possible to isolate both the testing and the SAST analysis to the component where changes were made. Just as this type of architecture simplifies many aspects of development, it pays off with SAST as well. It’s possible to analyze the component in isolation and get good results.

    3. Developer Analysis

    To further reduce SAST workload, start the first build without SAST, which removes the burden of the extra computation needed. Since subsequent builds are a lot smaller and build speed is much faster.

    However, there is an increase in false negatives due to the smaller scope of analysis since only files that changed are analyzed. This smaller scope means that all possible dependencies are outside the program model and are not considered in the analysis. However, this rapid analysis works well with coding standard enforcement, for example.

    Developer SAST

    Where to Start?

    Begin with a full build and analysis. This sets a baseline for detected bugs and vulnerabilities and establishes a performance target for reducing build time. This step will determine the exact number of lines of code, how long the analysis takes and its impact on build server load. These metrics should drive the analysis optimization effort.

    Given the options, the first step should be a component-based analysis. If this works well, it’s still possible to further reduce analysis with incremental and developer analysis within components. This approach can be integrated into typical developer workflows.

    When creating a developer branch for implementing changes, quick developer local analysis will catch local errors. These tend to be the largest set since they represent the largest part of the code changes. When enforcing coding standards, this is the point where violations are identified. A full analysis is recommended on a merge request to detect remaining defects related to cross-component-boundary behavior.

    Speed up SAST

    To speed up SAST consider using these techniques at the appropriate development stage to reduce time to complete, while still producing excellent results. Keep in mind that:
    ● Complete analysis yields the best and most precise results,
    ● Incremental analysis only analyzes recompiled code that has been modified,
    ● Component analysis works well in software that follows a well-defined component architecture and
    ● Developer (local) analysis provides a good compromise of precision and analysis time.

  • Code Security: SAST, Shift-Left, DevSecOps and Beyond

    Code Security: SAST, Shift-Left, DevSecOps and Beyond

    Automation is the key to pushing code security beyond DevSecOps

    In virtually every industry, developers are dealing with ensuring the safety of their code. Regardless of whether it’s enterprise or applications for automotive, aviation or industrial controls, small systems or large systems, every organization struggles with security. In response, the industry continues to evolve to improve automation, speed of delivery and code reliability. Let’s consider the key building blocks of today’s application development ecosystem.

    Static analysis or static application security testing (SAST) helps enforce coding guidelines and detect undefined behavior, and is commonly used across the development ecosystem. One advantage of SAST is automation. Since it doesn’t require input, SAST is easy to introduce into an existing software development process where it will inspect source code builds and generate warnings. Coding guidelines such as MISRA, CERT C and others help avoid common programming mistakes. However, a second category, undefined behavior, is a bigger issue. That’s because undefined behavior introduces risk. For example, a null pointer dereference, buffer overrun or uninitialized variable are exploitable vulnerabilities. Depending on their severity, they typically will require issuing a patch for customers.

    Next, let’s consider DevSecOps, which spans development, security and operations. Although it is becoming widely adopted in enterprise markets such as financial services, markets such as automotive and industrial are lagging. Nevertheless, the emphasis on security is driving the DevSecOps push to make life easier for software developers and to bring them more in line with security and operations functions.

    For example, quick feedback cycles are extremely important in every industry. Consider a use case in which it can take up to an hour to deploy a newly developed feature or a fix once it is written. That’s unthinkable in today’s day and age when new source code must run almost instantaneously.

    One of the most important elements in DevSecOps revolves around a project’s branching strategy. In addition to the main branch, every developer uses their own separate branch. They develop their code and then merge it back into that main branch. A key requirement for the main branch is to maintain zero unresolved warnings so that it passes all functional testing.

    Therefore, before a developer on an individual branch can submit their work, it also needs to pass all functional tests. And all static analysis tests need to pass. When a pull request or merge request has unresolved warnings, it is rejected, must be fixed and resubmitted. These include functional test case failures and static analysis warnings.

    Functional test failures must be fixed. However, the root cause of the failure may be hard to find. A functional test error might say, “Input A should generate output B,” but C comes out instead, but there is no indication as to which piece of code to change. Static analysis, on the other hand, will reveal exactly where there is a memory leak and will provide detailed explanations for each warning. This is one way in which static analysis can help DevSecOps deliver the best and most secure code.

    Finally, let’s review Lean and shift-left, and see how they are connected.

    Lean development is focused on delivering value to the business. If we fix this defect, is the business going to get value? If we fix this warning, is the business going to get value? In other words, eliminate waste, make the right decisions, at the right point in time.

    Zero defects is actually one of the big underlying philosophies behind Lean. And of course, zero defects never means zero defects. It really means near-zero defects. For example, when there’s no value in fixing a particular defect, it can be classified as don’t fix. Meanwhile, if a defect exists such that an application will behave badly when a user inputs a negative value in the add function, there are two options: Fix it or don’t fix it, if the expectation is users will never input negative values.

    The objective is to achieve a zero-defect baseline and continuously improve. In this scenario, zero defects refers to source code problems as well as warnings from static analysis.

    Last is the concept of shift-left, which is a movement to bring certain processes closer to the developer—testing, in this case. By providing faster feedback cycles on new code, developers can avoid slowdowns. When working on source code projects, if regression tests run several days after a block is submitted and reveal defects, it can be difficult for developers to recall what they worked on at the time. Faster feedback that occurs in minutes, not days, improves quality and security. In this way, shift-left is a central component of DevSecOps and Lean. And static analysis is part of that shift-left.

    So what’s next? In a word, more automation. Making sure developers have as little cognitive overhead as possible will allow them to build code faster and more securely. This can be achieved by combining the concepts described above as well as analyzing code as soon as new functionality is developed using behavior-based testing or test-driven development. The ultimate goal is faster feedback cycles that accelerate development cycles.