Authors:
(1) Amit Seal Ami, Computer Science Department, William & Mary Williamsburg, Virginia, USA, and this author contributed equally to this paper (aami@wm.edu);
(2) Syed Yusuf Ahmed, Institute for Information Technology, University of Dhaka Dhaka, Bangladesh, and this author contributed equally to this paper (bsse1013@iit.du.ac.bd);
(3) Radowan Mahmud Redoy, Institute for Information Technology, University of Dhaka Dhaka, Bangladesh, and this author contributed equally to this paper (bsse1002@iit.du.ac.bd);
(4) Nathan Cooper, Computer Science Department, William & Mary Williamsburg, Virginia, USA (nacooper01@wm.edu);
(5) Kaushal Kafle, Computer Science Department, William & Mary Williamsburg, Virginia, USA (kkafle@wm.edu);
(6) Kevin Moran, Department of Computer Science, University of Central Florida Orlando, Florida, USA (kpmoran@ucf.edu);
(7) Denys Poshyvanyk, Computer Science Department, William & Mary Williamsburg, Virginia, USA (denys@cs.wm.edu);
(8) Adwait Nadkarni, Computer Science Department, William & Mary Williamsburg, Virginia, USA (apnadkarni@wm.edu).
Table of Links
6 Future Work and Conclusion, Acknowledgments, and References
3 DESIGN GOALS
We considered several goals while designing MASC, while leaning on the experience we gained from the original version.
Diversity of Crypto-APIs (DG1): Effectively evaluating crypto-detectors requires considering misuse cases of existing crypto-APIs, which is challenging as crypto-APIs are as vast as the primitives
they enable. To address this, the crypto-API mutation operators need to be decoupled from the crypto-APIs. Such implementation would mean that even in the case when new crypto APIs are introduced, MASC can still create mutated misuse cases as long as the new crypto-APIs follow existing design principles.
Open to Extension (DG2): While both original and current implementations of MASC come with 12 generalizable mutation operators, these represent a subset of different expressions of misuse cases. Hence, MASC should be open to extension by stakeholders so that they can create their own mutation operators that can be easily plugged-in to MASC, without needing to modify MASC.
Ease of Evaluating Crypto-detectors (DG3): While the original, semiautomated implementation of MASC required manual evaluating the target crypto-detector, such heavy-lifting manual effort can not be simply expected from end-users. Part of this manual effort was unavoidable due to the unique, varied outputs produced by cryptodetectors. However, with the recent focus on using crypto-detectors with CI/CD pipelines and the introduction of the de-facto SARIF [15] formatted outputs, it would become possible to not only automate the entire evaluation process, but also make it customizable.
Adapting to Users (DG4): Finally, MASC should be created in such a way that it is usable by users of varying skills and in different environments. For instance, it should be usable as a stand-alone binary in a windowless server environment as a component, and as a front-end based software that can leverage the binary of itself.
This paper is available on arxiv under CC BY-NC-SA 4.0 DEED license.