DOCSLIB.ORG

Guidelines for the Use of the C++14 Language in Critical and Safety-Related Systems AUTOSAR AP Release 17-03

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Guidelines for the Use of the C++14 Language in Critical and Safety-Related Systems AUTOSAR AP Release 17-03 Guidelines for the use of the C++14 language in critical and safety-related systems AUTOSAR AP Release 17-03 Guidelines for the use of the Document Title C++14 language in critical and safety-related systems Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification No 839 Document Status Final Part of AUTOSAR Standard Adaptive Platform Part of Standard Release 17-03 Document Change History Date Release Changed by Description AUTOSAR 2017-03-31 17-03 Release • Initial release Management 1 of 371 Document ID 839: AUTOSAR_RS_CPP14Guidelines — AUTOSAR CONFIDENTIAL — Guidelines for the use of the C++14 language in critical and safety-related systems AUTOSAR AP Release 17-03 Disclaimer This work (specification and/or software implementation) and the material contained in it, as released by AUTOSAR, is for the purpose of information only. AUTOSAR and the companies that have contributed to it shall not be liable for any use of the work. The material contained in this work is protected by copyright and other types of intellectual property rights. The commercial exploitation of the material contained in this work requires a license to such intellectual property rights. This work may be utilized or reproduced without any modification, in any form or by any means, for informational purposes only. For any other purpose, no part of the work may be utilized or reproduced, in any form or by any means, without permission in writing from the publisher. The work has been developed for automotive applications only. It has neither been developed, nor tested for non-automotive applications. The word AUTOSAR and the AUTOSAR logo are registered trademarks. 2 of 371 Document ID 839: AUTOSAR_RS_CPP14Guidelines — AUTOSAR CONFIDENTIAL — Guidelines for the use of the C++14 language in critical and safety-related systems AUTOSAR AP Release 17-03 Table of Contents 1 Background7 2 The vision8 2.1 Rationale for the production of AUTOSAR C++14............8 2.2 Objectives of AUTOSAR C++14......................8 3 Scope 10 3.1 Allowed features of C++ language..................... 10 3.2 Limitations.................................. 13 4 Using AUTOSAR C++14 14 5 Introduction to the rules 15 5.1 Rule classification.............................. 15 5.1.1 Rule classification according to compatibility with MISRA.. 15 5.1.2 Rule classification according to obligation level........ 15 5.1.3 Rule classification according to enforcement by static analysis 15 5.1.4 Rule classification according to allocated target........ 16 5.2 Organization of rules............................ 16 5.3 Exceptions to the rules........................... 16 5.4 Redundancy in the rules.......................... 16 5.5 Presentation of rules............................ 17 5.6 Understanding the issue references.................... 17 5.7 Scope of rules................................ 17 6 AUTOSAR C++14 coding rules 18 6.0 Language independent issues....................... 18 6.0.1 Unnecessary constructs..................... 18 6.0.2 Storage.............................. 23 6.0.3 Runtime failures......................... 23 6.0.4 Arithmetic............................. 24 6.1 General................................... 26 6.1.1 Scope............................... 26 6.1.2 Normative references...................... 28 6.1.4 Implementation compliance................... 29 6.2 Lexical conventions............................. 30 6.2.3 Character sets.......................... 30 6.2.5 Trigraph sequences....................... 31 6.2.6 Alternative tokens........................ 31 6.2.8 Comments............................ 32 6.2.9 Header names.......................... 36 6.2.11 Identifiers............................. 36 6.2.14 Literals.............................. 41 6.3 Basic concepts............................... 44 3 of 371 Document ID 839: AUTOSAR_RS_CPP14Guidelines — AUTOSAR CONFIDENTIAL — Guidelines for the use of the C++14 language in critical and safety-related systems AUTOSAR AP Release 17-03 6.3.1 Declarations and definitions................... 44 6.3.2 One Definition Rule....................... 46 6.3.3 Scope............................... 47 6.3.4 Name lookup........................... 51 6.3.9 Types............................... 51 6.4 Standard conversions........................... 52 6.4.5 Integral promotions....................... 52 6.4.7 Integral conversion........................ 55 6.4.10 Pointer conversions....................... 57 6.5 Expressions................................. 58 6.5.0 General.............................. 58 6.5.1 Primary expression....................... 67 6.5.2 Postfix expressions....................... 75 6.5.3 Unary expressions........................ 83 6.5.6 Multiplicative operators..................... 84 6.5.8 Shift operators.......................... 85 6.5.10 Equality operators........................ 86 6.5.14 Logical AND operator...................... 86 6.5.16 Conditional operator....................... 87 6.5.18 Assignment and compound assignment operation...... 87 6.5.19 Comma operator......................... 87 6.5.20 Constant expression....................... 88 6.6 Statements................................. 88 6.6.2 Expression statement...................... 88 6.6.3 Compound statement or block................. 89 6.6.4 Selection statements...................... 89 6.6.5 Iteration statements....................... 91 6.6.6 Jump statements......................... 94 6.7 Declaration................................. 96 6.7.1 Specifiers............................. 96 6.7.2 Enumeration declaration.................... 104 6.7.3 Namespaces........................... 109 6.7.4 The asm declaration....................... 109 6.7.5 Linkage specification...................... 111 6.8 Declarators................................. 115 6.8.0 General.............................. 115 6.8.2 Ambiguity resolution....................... 115 6.8.3 Meaning of declarators..................... 116 6.8.4 Function definitions....................... 116 6.8.5 Initilizers............................. 118 6.9 Classes................................... 125 6.9.3 Member function......................... 125 6.9.5 Unions.............................. 128 6.9.6 Bit-fields............................. 128 6.10 Derived Classes............................... 130 6.10.1 Multiple base Classes...................... 130 4 of 371 Document ID 839: AUTOSAR_RS_CPP14Guidelines — AUTOSAR CONFIDENTIAL — Guidelines for the use of the C++14 language in critical and safety-related systems AUTOSAR AP Release 17-03 6.10.2 Member name lookup...................... 132 6.10.3 Virtual functions......................... 133 6.11 Member access control........................... 139 6.11.0 General.............................. 139 6.11.3 Friends.............................. 142 6.12 Special member functions......................... 142 6.12.0 General.............................. 142 6.12.1 Constructors........................... 143 6.12.4 Destructors............................ 149 6.12.6 Initialization............................ 151 6.12.7 Construction and destructions................. 153 6.12.8 Copying and moving class objects............... 155 6.13 Overloading................................. 167 6.13.1 Overloadable declarations................... 167 6.13.2 Declaration matching...................... 170 6.13.3 Overload resolution....................... 173 6.13.5 Overloaded operators...................... 174 6.13.6 Build-in operators........................ 175 6.14 Templates.................................. 176 6.14.0 General.............................. 176 6.14.1 Template parameters...................... 176 6.14.5 Template declarations...................... 179 6.14.6 Name resolution......................... 179 6.14.7 Template instantiation and specialization........... 179 6.14.8 Function template specializations............... 181 6.15 Exception handling............................. 183 6.15.0 General.............................. 186 6.15.1 Throwing an exception..................... 201 6.15.2 Constructors and destructors.................. 211 6.15.3 Handling an exception...................... 215 6.15.4 Exception specifications..................... 225 6.15.5 Special functions......................... 234 6.16 Preprocessing directives.......................... 241 6.16.0 General.............................. 241 6.16.1 Conditional inclusion....................... 244 6.16.2 Source file inclusion....................... 245 6.16.3 Macro replacement....................... 247 6.16.6 Error directive.......................... 248 6.16.7 Pragma directive......................... 249 6.17 Library introduction - partial........................ 249 6.17.1 General.............................. 249 6.17.2 The C standard library...................... 251 6.17.3 Definitions............................ 252 6.18 Language support library - partial..................... 253 6.18.0 General.............................. 253 6.18.1 Types............................... 254 5 of 371 Document ID 839: AUTOSAR_RS_CPP14Guidelines — AUTOSAR CONFIDENTIAL — Guidelines for the use of the C++14 language in critical and safety-related systems AUTOSAR AP Release 17-03 6.18.2 Implementation properties................... 258 6.18.5 Dynamic memory management................ 259 6.18.9 Other runtime support...................... 268 6.19 Diagnostics library - partial......................... 272 6.19.4 Error numbers.......................... 272 6.23 Containers library - partial........................
Load more

Recommended publications
  • Functional Languages
    Functional Programming Languages (FPL) 1. Definitions................................................................... 2 2. Applications ................................................................ 2 3. Examples..................................................................... 3 4. FPL Characteristics:.................................................... 3 5. Lambda calculus (LC)................................................. 4 6. Functions in FPLs ....................................................... 7 7. Modern functional languages...................................... 9 8. Scheme overview...................................................... 11 8.1. Get your own Scheme from MIT...................... 11 8.2. General overview.............................................. 11 8.3. Data Typing ...................................................... 12 8.4. Comments ......................................................... 12 8.5. Recursion Instead of Iteration........................... 13 8.6. Evaluation ......................................................... 14 8.7. Storing and using Scheme code ........................ 14 8.8. Variables ........................................................... 15 8.9. Data types.......................................................... 16 8.10. Arithmetic functions ......................................... 17 8.11. Selection functions............................................ 18 8.12. Iteration............................................................. 23 8.13. Defining functions ...........................................
    [Show full text]
  • Integers in C: an Open Invitation to Security Attacks?
    Integers In C: An Open Invitation To Security Attacks? Zack Coker Samir Hasan Jeffrey Overbey [email protected] [email protected] [email protected] Munawar Hafiz Christian Kästnery [email protected] Auburn University yCarnegie Mellon University Auburn, AL, USA Pittsburgh, PA, USA ABSTRACT integer type is assigned to a location with a smaller type, We performed an empirical study to explore how closely e.g., assigning an int value to a short variable. well-known, open source C programs follow the safe C stan- Secure coding standards, such as MISRA's Guidelines for dards for integer behavior, with the goal of understanding the use of the C language in critical systems [37] and CERT's how difficult it is to migrate legacy code to these stricter Secure Coding in C and C++ [44], identify these issues that standards. We performed an automated analysis on fifty-two are otherwise allowed (and sometimes partially defined) in releases of seven C programs (6 million lines of preprocessed the C standard and impose restrictions on the use of inte- C code), as well as releases of Busybox and Linux (nearly gers. This is because most of the integer issues are benign. one billion lines of partially-preprocessed C code). We found But, there are two cases where the issues may cause serious that integer issues, that are allowed by the C standard but problems. One is in safety-critical sections, where untrapped not by the safer C standards, are ubiquitous|one out of four integer issues can lead to unexpected runtime behavior. An- integers were inconsistently declared, and one out of eight other is in security-critical sections, where integer issues can integers were inconsistently used.
    [Show full text]
  • Language Subsetting in an Industrial Context: a Comparison of MISRA C 1998 and MISRA C 2004
    Language subsetting in an industrial context: a comparison of MISRA C 1998 and MISRA C 2004 Les Hatton CISM, University of Kingston∗ November 20, 2005 Abstract The MISRA C standard [7] first appeared in 1998 with the objective of providing a set of guidelines to restrict features in the ISO C language of known undefined or otherwise dangerous behaviour. The standard was assembled by representatives of a number of companies in the automobile sector in response to the rapidly growing use of C in electronic embedded systems in automobiles. The standard attempts to build on the earlier work of [6], [3] and others. Due to various perceived deficiencies, notably considerable ambiguity in the rule definitions, a revision was planned and eventually appeared in 2004. This paper measures how well the two stan- dards compare on the same population of software and also determines how well the 2004 version achieved its stated goals. Given its increasing influence, the results raise important concerns. Keywords: safer subsets, MISRA C, embedded control systems 1 Overview Pragmatic safer subsetting of languages to remove dependence on poorly defined features is finally becoming a mainstream activity with the recent recommen- dation to form a high-integrity study group under the auspices of the ISO, [8] with the intention of producing sets of rules to restrict features with undefined or otherwise dangerous behaviour in programming languages in common use. It frequently comes as a surprise to developers that significant parts of a pro- gramming language can fall into this category. In practice, all standardised programming languages contain problematic features for a variety of reasons which include the inability of the standardising committee to agree on the be- haviour of a particular feature, the use of unintentionally ambiguous language in the standards document itself, omitting to say anything at all and so on.
    [Show full text]
  • Contents Credits & Contacts
    overload issue 72 april 2006 contents credits & contacts Multithreading 101 Overload Editor: Alan Griffiths Tim Penhey 7 [email protected] [email protected] To Grin Again Contributing Editor: Alan Griffiths 10 Mark Radford [email protected] A Fistful of Idioms Steve Love 14 Advisors: Phil Bass C++ Best Practice: [email protected] Designing Header Files Thaddaeus Frogley Alan Griffiths 19 [email protected] Richard Blundell Visiting Alice [email protected] Phil Bass 24 Pippa Hennessy [email protected] Tim Penhey [email protected] Advertising: Thaddaeus Frogley [email protected] Overload is a publication of the ACCU. For details of the ACCU and other ACCU publications and activities, see the ACCU website. ACCU Website: http://www.accu.org/ Information and Membership: Join on the website or contact David Hodge [email protected] Publications Officer: John Merrells [email protected] Copy Deadlines All articles intended for publication in Overload 73 should be submitted to the editor by ACCU Chair: May 1st 2006, and for Overload 74 by July 1st 2006. Ewan Milne [email protected] 3 overload issue 72 april 2006 Editorial: Doing What You Can Your magazine needs you! f you look at the contents of this issue of Overload you’ll see that most of the feature content has been written by the editorial team.You might even notice that the remaining Iarticle is not new material. To an extent this is a predictable consequence of the time of year: many of the potential contributors are busy preparing for the conference. However, as editor for the last couple of years I’ve noticed More on WG14 that there is a worrying decline in proposals for articles Last time I commented on the fact that I was hearing from authors.
    [Show full text]
  • Command Line Interface
    Command Line Interface Squore 21.0.2 Last updated 2021-08-19 Table of Contents Preface. 1 Foreword. 1 Licence. 1 Warranty . 1 Responsabilities . 2 Contacting Vector Informatik GmbH Product Support. 2 Getting the Latest Version of this Manual . 2 1. Introduction . 3 2. Installing Squore Agent . 4 Prerequisites . 4 Download . 4 Upgrade . 4 Uninstall . 5 3. Using Squore Agent . 6 Command Line Structure . 6 Command Line Reference . 6 Squore Agent Options. 6 Project Build Parameters . 7 Exit Codes. 13 4. Managing Credentials . 14 Saving Credentials . 14 Encrypting Credentials . 15 Migrating Old Credentials Format . 16 5. Advanced Configuration . 17 Defining Server Dependencies . 17 Adding config.xml File . 17 Using Java System Properties. 18 Setting up HTTPS . 18 Appendix A: Repository Connectors . 19 ClearCase . 19 CVS . 19 Folder Path . 20 Folder (use GNATHub). 21 Git. 21 Perforce . 23 PTC Integrity . 25 SVN . 26 Synergy. 28 TFS . 30 Zip Upload . 32 Using Multiple Nodes . 32 Appendix B: Data Providers . 34 AntiC . 34 Automotive Coverage Import . 34 Automotive Tag Import. 35 Axivion. 35 BullseyeCoverage Code Coverage Analyzer. 36 CANoe. 36 Cantata . 38 CheckStyle. ..
    [Show full text]
  • Understanding Integer Overflow in C/C++
    Appeared in Proceedings of the 34th International Conference on Software Engineering (ICSE), Zurich, Switzerland, June 2012. Understanding Integer Overflow in C/C++ Will Dietz,∗ Peng Li,y John Regehr,y and Vikram Adve∗ ∗Department of Computer Science University of Illinois at Urbana-Champaign fwdietz2,[email protected] ySchool of Computing University of Utah fpeterlee,[email protected] Abstract—Integer overflow bugs in C and C++ programs Detecting integer overflows is relatively straightforward are difficult to track down and may lead to fatal errors or by using a modified compiler to insert runtime checks. exploitable vulnerabilities. Although a number of tools for However, reliable detection of overflow errors is surprisingly finding these bugs exist, the situation is complicated because not all overflows are bugs. Better tools need to be constructed— difficult because overflow behaviors are not always bugs. but a thorough understanding of the issues behind these errors The low-level nature of C and C++ means that bit- and does not yet exist. We developed IOC, a dynamic checking tool byte-level manipulation of objects is commonplace; the line for integer overflows, and used it to conduct the first detailed between mathematical and bit-level operations can often be empirical study of the prevalence and patterns of occurrence quite blurry. Wraparound behavior using unsigned integers of integer overflows in C and C++ code. Our results show that intentional uses of wraparound behaviors are more common is legal and well-defined, and there are code idioms that than is widely believed; for example, there are over 200 deliberately use it.
    [Show full text]
  • 5. Data Types
    IEEE FOR THE FUNCTIONAL VERIFICATION LANGUAGE e Std 1647-2011 5. Data types The e language has a number of predefined data types, including the integer and Boolean scalar types common to most programming languages. In addition, new scalar data types (enumerated types) that are appropriate for programming, modeling hardware, and interfacing with hardware simulators can be created. The e language also provides a powerful mechanism for defining OO hierarchical data structures (structs) and ordered collections of elements of the same type (lists). The following subclauses provide a basic explanation of e data types. 5.1 e data types Most e expressions have an explicit data type, as follows: — Scalar types — Scalar subtypes — Enumerated scalar types — Casting of enumerated types in comparisons — Struct types — Struct subtypes — Referencing fields in when constructs — List types — The set type — The string type — The real type — The external_pointer type — The “untyped” pseudo type Certain expressions, such as HDL objects, have no explicit data type. See 5.2 for information on how these expressions are handled. 5.1.1 Scalar types Scalar types in e are one of the following: numeric, Boolean, or enumerated. Table 17 shows the predefined numeric and Boolean types. Both signed and unsigned integers can be of any size and, thus, of any range. See 5.1.2 for information on how to specify the size and range of a scalar field or variable explicitly. See also Clause 4. 5.1.2 Scalar subtypes A scalar subtype can be named and created by using a scalar modifier to specify the range or bit width of a scalar type.
    [Show full text]
  • Signedness-Agnostic Program Analysis: Precise Integer Bounds for Low-Level Code
    Signedness-Agnostic Program Analysis: Precise Integer Bounds for Low-Level Code Jorge A. Navas, Peter Schachte, Harald Søndergaard, and Peter J. Stuckey Department of Computing and Information Systems, The University of Melbourne, Victoria 3010, Australia Abstract. Many compilers target common back-ends, thereby avoid- ing the need to implement the same analyses for many different source languages. This has led to interest in static analysis of LLVM code. In LLVM (and similar languages) most signedness information associated with variables has been compiled away. Current analyses of LLVM code tend to assume that either all values are signed or all are unsigned (except where the code specifies the signedness). We show how program analysis can simultaneously consider each bit-string to be both signed and un- signed, thus improving precision, and we implement the idea for the spe- cific case of integer bounds analysis. Experimental evaluation shows that this provides higher precision at little extra cost. Our approach turns out to be beneficial even when all signedness information is available, such as when analysing C or Java code. 1 Introduction The “Low Level Virtual Machine” LLVM is rapidly gaining popularity as a target for compilers for a range of programming languages. As a result, the literature on static analysis of LLVM code is growing (for example, see [2, 7, 9, 11, 12]). LLVM IR (Intermediate Representation) carefully specifies the bit- width of all integer values, but in most cases does not specify whether values are signed or unsigned. This is because, for most operations, two’s complement arithmetic (treating the inputs as signed numbers) produces the same bit-vectors as unsigned arithmetic.
    [Show full text]
  • General Specification of Basic Software Modules AUTOSAR CP R19-11
    General Specification of Basic Software Modules AUTOSAR CP R19-11 Document Title General Specification of Basic Software Modules Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification No 578 Document Status published Part of AUTOSAR Standard Classic Platform Part of Standard Release R19-11 Document Change History Date Release Changed by Change Description 2019-11-28 R19-11 AUTOSAR Include guard for header files Release minor corrections / clarifications / Management editorial changes; For details please refer to the ChangeDocumentation Changed Document Status from Final to published 2018-10-31 4.4.0 AUTOSAR minor corrections / clarifications / Release editorial changes; For details please Management refer to the ChangeDocumentation 2017-12-08 4.3.1 AUTOSAR minor corrections / clarifications / Release editorial changes; For details please Management refer to the ChangeDocumentation 2016-11-30 4.3.0 AUTOSAR Meta Data handling Release Changed to MISRA C 2012 Management Standard Debugging support was removed minor corrections / clarifications / editorial changes; For details please refer to the ChangeDocumentation 2015-07-31 4.2.2 AUTOSAR Debugging support marked as Release obsolete Management minor corrections / clarifications / editorial changes; For details please refer to the ChangeDocumentation 1 of 86 Document ID 578: AUTOSAR_SWS_BSWGeneral - AUTOSAR confidential - General Specification of Basic Software Modules AUTOSAR CP R19-11 Document Change History Date Release Changed by Change Description 2014-10-31
    [Show full text]
  • MISRA-C Subset of the C Language for Critical Systems SAFETY-CRITICAL SYSTEMS
    MISRA-C Subset of the C language for critical systems SAFETY-CRITICAL SYSTEMS System is safety-critical if people might die due to software bugs Examples Automobile stability / traction control Medical automation Many military applications You develop safety-critical software differently from non-critical software MISRA-C MISRA – Motor Industry Software Reliability Association Their bright idea: Can’t avoid C But can force developers to avoid features of C that are known to be problematic Some language flaws Some legitimate features that happen to be bad for embedded software Most of MISRA-C is just good common sense for any C programmer TERMINOLOGY Execution error: Something illegal done by a program Out-of-bounds array reference Divide by zero Uninitialized variable usage Trapped execution error: Immediately results in exception or program termination Untrapped execution error: Program keeps running But may fail in an unexpected way later on E.g., due to corrupted RAM In C, operations with undefined behavior are not trapped SAFETY A safe language does not allow untrapped execution errors A statically safe language catches all execution errors at compile time Useful languages can’t be completely statically safe Java is dynamically safe C and C++ are very unsafe MISRA C is not safe either However, adherence to MISRA-C can largely be statically checked This eliminates or reduces the likelihood of some kinds of untrapped execution errors MISRA-C RULE 1.2 No reliance shall be placed on undefined or unspecified behavior. Lots of things in C have undefined behavior Divide by zero Out-of-bounds memory access Signed integer overflow Lots of things in C have implementation-defined and unspecified behavior printf (“a”) + printf (“b”); Both of these hard to detect at compile time, in general Implementation-defined behavior is fine in MISRA-C Why? MISRA-C RULE 5.2 Identifiers in an inner scope shall not use the same name as an identifier in an outer scope, and therefore hide that identifier.
    [Show full text]
  • (Pdf) of from Push/Enter to Eval/Apply by Program Transformation
    From Push/Enter to Eval/Apply by Program Transformation MaciejPir´og JeremyGibbons Department of Computer Science University of Oxford [email protected] [email protected] Push/enter and eval/apply are two calling conventions used in implementations of functional lan- guages. In this paper, we explore the following observation: when considering functions with mul- tiple arguments, the stack under the push/enter and eval/apply conventions behaves similarly to two particular implementations of the list datatype: the regular cons-list and a form of lists with lazy concatenation respectively. Along the lines of Danvy et al.’s functional correspondence between def- initional interpreters and abstract machines, we use this observation to transform an abstract machine that implements push/enter into an abstract machine that implements eval/apply. We show that our method is flexible enough to transform the push/enter Spineless Tagless G-machine (which is the semantic core of the GHC Haskell compiler) into its eval/apply variant. 1 Introduction There are two standard calling conventions used to efficiently compile curried multi-argument functions in higher-order languages: push/enter (PE) and eval/apply (EA). With the PE convention, the caller pushes the arguments on the stack, and jumps to the function body. It is the responsibility of the function to find its arguments, when they are needed, on the stack. With the EA convention, the caller first evaluates the function to a normal form, from which it can read the number and kinds of arguments the function expects, and then it calls the function body with the right arguments.
    [Show full text]
  • Coverity Static Analysis
    Coverity Static Analysis Quickly find and fix Overview critical security and Coverity® gives you the speed, ease of use, accuracy, industry standards compliance, and quality issues as you scalability that you need to develop high-quality, secure applications. Coverity identifies code critical software quality defects and security vulnerabilities in code as it’s written, early in the development process when it’s least costly and easiest to fix. Precise actionable remediation advice and context-specific eLearning help your developers understand how to fix their prioritized issues quickly, without having to become security experts. Coverity Benefits seamlessly integrates automated security testing into your CI/CD pipelines and supports your existing development tools and workflows. Choose where and how to do your • Get improved visibility into development: on-premises or in the cloud with the Polaris Software Integrity Platform™ security risk. Cross-product (SaaS), a highly scalable, cloud-based application security platform. Coverity supports 22 reporting provides a holistic, more languages and over 70 frameworks and templates. complete view of a project’s risk using best-in-class AppSec tools. Coverity includes Rapid Scan, a fast, lightweight static analysis engine optimized • Deployment flexibility. You for cloud-native applications and Infrastructure-as-Code (IaC). Rapid Scan runs decide which set of projects to do automatically, without additional configuration, with every Coverity scan and can also AppSec testing for: on-premises be run as part of full CI builds with conventional scan completion times. Rapid Scan can or in the cloud. also be deployed as a standalone scan engine in Code Sight™ or via the command line • Shift security testing left.
    [Show full text]